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Prefácio 


Cenário atual das aplicacoes web 


Atualmente, vivemos em uma fase na qual a maioria dos usuários utilizam 
diversos tipos de devices para se conectarem à internet. Os mais populares sáo 
smartphones, tablets e notebooks. Desenvolver sistemas para diversos tipos 





de devices requer o trabalho de construir Web services, também conhecidos 
pelo nome de APIs (Application Program Interface), 

Basicamente, essas APIs são sistemas back-end que têm o objetivo de tra- 
balhar apenas com dados, de forma centralizada, permitindo que sejam de- 
senvolvidos, separadamente, aplicações clientes que possuem interfaces para 
o usuário final. Essas aplicações clientes geralmente são: mobile apps, aplica- 


ções desktop ou web apps, 


Desde 2010 até os dias de hoje, o Node.js cada vez mais provou ser uma 





plataforma excelente na solução de diversos problemas, principalmente para 
construção de APIs RESTful, Sua arquitetura Single Thread que realiza I/O 
não bloqueante rodando em cima do JavaScript — que é uma linguagem muito 
presente em praticamente todos os browsers atuais — demonstrou uma boa 
eficiência no processamento de muitas aplicações atuais. 

Existem alguns casos de empresas grandes, como por exemplo, LinkedIn 
e PayPal, que economizaram significativamente gastos com servidores ao mi- 
grar alguns de seus projetos para o Node.js. 

E uma outra vantagem do uso do Node.js, que cativou muitos desenvol- 
vedores, foi a sua curva baixa de aprendizado. Afinal, quem já trabalha com 


desenvolvimento web já possui, pelo menos, um conhecimento básico sobre 
a linguagem JavaScript. 


vil 
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A quem se destina este livro? 


Este livro é destinado aos desenvolvedores web que tenham pelo menos 
conhecimentos básicos de JavaScript e. principalmente, conheçam bem sobre 
Orientação a Objetos (OO). arquitetura cliente-servidor e que tenham noções 
das principais características sobre API RESTful. 

Ter domínio desses conceitos, mesmo que seja um conhecimento básico 
deles, será essencial para que a leitura deste livro seja de fácil entendimento. 

Algo bem legal do livro é que todos os códigos utilizarão a mais recente 
implementação do JavaScript, o EcmaScript 2015 (também conhecido pelos 
nomes EcmaScript 6 ou ES6). 


Como devo estudar? 


Ao decorrer da leitura, serão apresentados diversos conceitos e códigos, 
para que você aprenda na prática toda a parte teórica do livro. Ele o guiará de 
forma didática no desenvolvimento de dois projetos (uma API e um cliente 
web). que no final serão integrados para funcionar como um único projeto. 


Você pode discutir sobre este livro no Fórum da Casa do Código: http: 


//forum.casadocodigo.com.br/. 





Atenção: É recomendado seguir passo a passo as instruções do livro. para 
no final você concluir o projeto corretamente. 
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Capítulo | 


Introdução ao Node.js 


1.1 O que é Node.js? 


nedes 


Fig. 1.1: Logo do Node.js 


O Node.js é uma plataforma altamente escalável e de baixo nível. Nele, você 





vai programar diretamente com diversos protocolos de rede e internet, ou uti- 


1.2. Principais características Casa do Códi 


lizar bibliotecas que acessam diversos recursos do sistema operacional. Para 
programar em Node.js, basta dominar a linguagem JavaScript — isso mesmo, 
JavaScript! E o runtime JavaScript utilizado nesta plataforma é o famoso Ja- 
vascript V8, que é usado também no Google Chrome. 


12 Principais características 


Single-thread 
Suas aplicações serão single-thread, ou seja, cada aplicação terá instância de 
uma thread principal por processo iniciado. Se você está acostumado a tra- 
balhar com programação multi-thread — como Java ou NET —, infelizmente 
não será possível com Node.js. Porém, existem outras maneiras de se criar 
um sistema que trabalhe com processamento paralelo. 

Por exemplo. você pode utilizar uma biblioteca nativa do Node.js cha- 
mada clusters, que permite implementar um rede de múltiplos processos 
de sua aplicação. Nele você pode criar N-1 processos de sua aplicação para 
trabalhar com processamento, enquanto o processo principal se encarrega de 
balancear a carga entre os demais processos. Se a CPU do seu servidor possui 
múltiplos núcleos, aplicar essa técnica vai otimizar o seu uso. 

Outra maneira é adotar a programação assíncrona, que é um dos prin- 
cipais recursos da linguagem JavaScript. As funções assíncronas no Node.js 
trabalham com I/O não bloqueante. ou seja, caso sua aplicação tenha de ler 
um imenso arquivo, ela não vai bloquear a CPU, permitindo que ela continue 
disponível para processar outras tarefas da aplicação realizadas por outros 
usuários. 


Observação 


Não se preocupe em entender tudo isso agora, pois veremos mais so- 
bre isso no decorrer do livro. 





Event-Loop 


Node.js é orientado a eventos. Ele segue a mesma filosofia de orientação 


Casa do Código Capítulo 1. Introduç ão ao Node.js 


de eventos do JavaScript client-side; a única diferença são os tipos de even- 
tos, ou seja, nào existem eventos de Click do mouse, keyup do teclado ou 
qualquer evento de componentes do HTML. Na verdade, trabalhamos com 
eventos de I/O, como por exemplo: o evento connect de um banco de da- 
dos, um Open de um arquivo, um data de um streaming de dados e muitos 
outros. 


FILA DE EVENTOS EVENTOS EXECUTADOS 
Close Request 
Request Checando por Connection 


novos eventos 
Sa 


OS EVENTOS SÃO PROCESSADOS UM POR VEZ 


Fig. 12: Event-Loop do Node.js 


O Event-Loop é o agente responsável por escutar e emitir eventos. Na prá- 
tica, ele é basicamente um loop infinito que, a cada iteracáo, verifica em sua 
fila de eventos se um determinado evento foi disparado. Quando um evento é 
disparado, o Event-Loop executa e o envia para a fila de executados. Quando 
um evento está em execução, nós podemos programar qualquer lógica dentro 
dele, e isso tudo acontece graças ao mecanismo de callback de função do 
JavaScript. 
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1.3 Por que devo aprender Node.js? 


1) JavaScript everywhere: praticamente, o Node.js usa JavaScript como lin- 
guagem de programação server-side, Essa característica permite que vocé 
reduza e muito sua curva de aprendizado, afinal, a linguagem é a mesma 
do JavaScript Client-side, Seu desafio nesta plataforma será de aprender a 
fundo como funciona a programação assíncrona para se tirar maior pro- 
veito dessa técnica em sua aplicação. Outra vantagem de se trabalhar com 
JavaScript é que você vai manter um projeto de fácil manutenção — é claro, 
desde que saiba programar JavaScript de verdade! 


Você terá facilidade em procurar profissionais para seus projetos e gastará 


menos tempo estudando uma nova linguagem server-side. Uma vanta- 
gem técnica do JavaScript comparador com outras linguagens de back- 





end é que você não vai utilizar mais aqueles frameworks de serialização de 
objetos JSON (JavaScript Object Notation), afinal, o JSON client-side é o 
mesmo no server-side. Há também casos de aplicações usando banco de 
dados que persistem objetos JSON, um bom exemplo são os NoSQL Mon- 
goDB e CouchDB. Outro detalhe importante é que, atualmente, o Node.js 
adota diversas funcionalidades da implementação ECMAScript 6, permi- 
tindo a codificação de um JavaScript mais elegante e robusto. 


2) Comunidade ativa: esse é um dos pontos mais fortes do Node.js. Atual- 


mente, existem várias comunidades no mundo inteiro trabalhando muito 
para esta plataforma, seja divulgando posts e tutoriais, palestrando em 
eventos, ou principalmente publicando e mantendo novos módulos. Aqui 
no Brasil, temos três grupos bem ativos: 


* Google: https://groups.google.com/forum/Z!forum/nodebr 
e Facebook https://facebook.com/groups/nodejsbrasil 
* Slack: https://nodebr.slack.com 





3) Ótimos salários: desenvolvedores Node.js geralmente recebem bons sa- 
lários. Isso ocorre pelo fato de que infelizmente no Brasil ainda existem 
poucas empresas adotando essa tecnologia. Isso faz com que empresas que 
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necessitem dela paguem salários na média ou acima da média para man- 





terem esses desenvolvedores em seus projetos. Outro caso interessante são 
as empresas que contratam estagiários ou programadores juniores que te- 
nham ao menos conhecimentos básicos de JavaScript, com o objetivo de 
treiná-los para trabalhar com Node.js. Neste caso, não espere um alto sa- 
lário, e sim um amplo conhecimento preenchendo o seu currículo. 


4) Ready for realtime: o Node.js ficou popular graças aos seus frameworks 





de interação realtime entre cliente e servidor. O SockJS e Socket.IO são 
bons exemplos. Eles sáo compatíveis com o recente protocolo WebSoc- 
kets e permitem trafegar dados através de uma ünica conexáo bidirecio- 
nal, tratando todas as mensagens por meio de eventos JavaScript. 


5) Big players: LinkedIn, Wallmart, Groupon, Microsoft, Netflix, Uber e 


Paypal são algumas das grandes empresas usando Node.js, e existe muito 





mais! 


Conclusão 


Até aqui, foi explicado toda teoria, conceitos e vantagens principais sobre 
por que usar o Node.js. Nos próximos capítulos, vamos partir para prática 





com uma única condição! Abra sua mente para o novo e leia este livro com 
total empolgação para que você o aproveite ao máximo. 
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Setup do ambiente 


Neste capítulo, explicarei como instalar o Node.js nos principais sistemas ope- 
racionais (Windows, Linux, MacOSX). Porém, no decorrer do livro, os exem- 
plos serão apresentados utilizando um MacOSX. 





Apesar de existirem algumas pequenas diferengas de código entre esses 
sistemas operacionais, fique tranquilo em relação a esse problema, pois os 
exemplos que serão aplicados neste livro são compatíveis com essas platafor- 
mas. 
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Para configurar um ambiente Node.js, independente de qual sistema operaci- 
onal, as dicas serão praticamente parecidas. Somente alguns procedimentos 
serão diferentes para cada sistema, principalmente para o Linux, mas não será 
nada grave. 
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Fig. 2.1: Homepage do Node.js 


O primeiro passo é acessar seu site oficial do Node.js: http://nodejs.org. 


Em seguida, clique no botão Install para baixar automaticamente 
a última versão compatível com seu sistema operacional Windows ou 
MacOSX. Caso você use Linux, recomendo que leia em detalhes a 
Wiki do repositório Node.js, em https://github.com/nodejs/node/wiki/ 
Installing-and-Building-Node.s. 

Nessa Wiki, é explicado como instalar de forma compilada para qualquer 
distribuição Linux. 

Após fazer o download do Node.js, instale-o normalmente. No caso do 
Windows e MacOSX, basta clicar no famoso botão Next inúmeras vezes até 
concluir a instalação, pois não há nenhuma configuração específica para ajus- 
tar. 

Para testar se tudo esta rodando corretamente, abra o terminal (para 
quem usa Linux ou MacOSX), ou prompt de comandos (se possível utilize 
o Power Shell) do Windows, e digite o seguinte comando: 


node -v && npm -v 
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Veja as respectivas versões do Node.js e NPM que foram instaladas. A 
última versão estável que será utilizada neste livro é o Node v52.0 junto com 
NPM 33.12. 


Sobre o merge do io.js com Node.js 


Desde o dia 8 de setembro de 2015, o Node.js passou da versão 0.12x 
para 5.2.0. Isso ocorreu devido a um merge de uma variação do Node.js 
chamada io.js. 

O io.js foi um fork realizado e mantido por um grupo da comuni- 
dade Node.js de governança aberta. Eles trabalharam muito na inclusão 
da nova implementação do ECMAScript 6. além da implementação de 
diversas outras melhorias que eram lentamente trabalhadas no Node js. 
Praticamente, a evolução do 10.js chegou até a versão 3.0.0, até que am- 
bos os grupos resolveram fundir o io.js de volta para o Node js, e assim 
surgiu a nova versão 4.0.0. Esse merge não só deu um imenso upgrade 
nesta plataforma como também tornou-a mais estável e confiável para 
adoção em projetos de grande porte. 

Neste livro, vamos usar a versào 52.0, assim como serào implemen- 
tados diversos códigos utilizando o novo padrão ECMAScript 6. 

Para conhecer as principais funcionalidades do novo JavaScript por 
meio de exemplos práticos, acesse esse site: http://es6-features.org. 





22 Instalação alternativa via NVM 
Atenção 


Você não é obrigado a instalar o Node.js via NVM. Nesta seção, es- 


tamos apenas explorando uma alternativa de instalação do Node.js via 
gerenciador de versão. Sinta-se à vontade para pular esta etapa caso você 
já tenha instalado o Node.js de forma convencional e nào sente vontade 
de gerenciar múltiplas versões do Node js. 
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Assim como a linguagem Ruby possui o RVM (Ruby Version Manager) 


para gerenciar múltiplas versões do Ruby em uma mesma máquina, o Node.js 
também possui um gerenciador, que é conhecido por NVM (Node Version 
Manager), 

O NVM éasolução perfeita para você que precisa testar o comportamento 
de seus projetos em distintas versões do Node.js. Ele também serve para a 
galera que curte testar versões unstables também. 





O grande benefício do NVM é que ele é prático, fácil de usar, desinstala 
uma versão Node.js em um único comando e lhe poupará um bom tempo 
na hora de instalar o Node.js. Ele é uma boa alternativa, principalmente em 
sistemas Linux cujos package manager nativos estão desatualizados e não vi- 
abilizam facilmente a instalação de uma versão recente do Node.js. 


Configurando o NVM 


Em poucas etapas, você configura o NVM para instalá-lo no MacOSX ou 
Linux, basta rodar este comando: 


curl https://raw.githubusercontent,com/creationix/nvm/v0.26.1 


/install.sh * 


| bash 


Infelizmente, o oficial NVM não esta disponível para Windows, mas exis- 
tem projetos alternativos criados pela comunidade. São duas alternativas bem 
semelhantes para o Windows: 


e NVMW: https://github.com/hakobera/nvmw 


* NVM-Windows: https://github.com/coreybutler/nvm-windows 


Ambos possuem uma interface de comandos muito parecida com o 
NVM. 


Principais comandos do NVM 


Como receita de bolo, a seguir apresento uma pequena lista com os prin- 
cipais comandos do NVM que serão essenciais para você gerenciar múltiplas 


10 


Casa do Código Capítulo 2. Setup do ambiente 


versões do Node.js, ou pelo menos manter seu ambiente atualizado com a 
última versão: 


nvm Is: lista todas as versões instaladas em sua máquina: 


nvm Is-remote: lista todas as versões disponíveis para download do 
site http://nodejs.org/dist; 


nvm install vX.X.X: baixa e instala uma versão do Node. js: 
nvm uninstall vX.X.X: desinstala uma versão Node.js; 


nvm use vX.X.X: escolhe uma versão Node.js existente para ser 
usada; 


nvm alias default vX.X.X: escolhe uma versão existente para 
ser carregada por padrão no início do sistema operacional: 


nvm help: lista todos os comandos do NVM. 


Atenção 


Nos comandos que foram citados VX.X.X você deve trocar o 


vX.X.X por uma versão Node.js de sua escolha, como por exemplo, 
v5.2.0 





Instalando Node.js via NVM 
Para instalar o Node.js via NVM, basta rodar os seguintes comandos: 


nvm install v5.2.0 
nvm use v5.2.0 


nvm alias default v5.2.0 


Após a execução desses comandos, você terá o Node.js pré-carregado ao 


iniciar o seu sistema operacional. 
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ll 


2.3. Test-drive no ambiente Casa do Código 


Testando Node.js via REPL 





Para testarmos o ambiente, executaremos o nosso primeiro programa de 
Hello World, sem criar arquivo de código. Volte ao terminal ou prompt de 





comando, e execute o comando: Node, Este vai acessar o modo REPL (Read- 
Eval-Print-Loop), que permite executar códigos JavaScript diretamente pela 
tela preta. 

Agora digite o comando:  console.log("Hello World"), Em se- 
guida, tecle ENTER para executá-lo na hora. Se tudo der certo, você verá um 
resultado parecido com a figura a seguir: 


LI - * | viga 





Fig. 2.2: Modo REPL do Node.js 


Testando Node.js executando código JavaScript 


Você também pode fazer um test-drive rodando um arquivo JavaScript 
contendo o mesmo código anterior. Para isso, crie o arquivo hello.js e 
inclua o seguinte código: 


console. log("Hello World"); 


Para executá-lo, basta acessar o diretório desse arquivo via terminal, e 
rodar o comando node hello.js para o mesmo resultado do anterior: 
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colo:workspace | 
Hello World 





Fig. 2.3: Rodando um arquivo JavaScript 


Conclusão 


Parabéns! Agora, além de ter tudo instalado e funcionando, também 
aprendeu um novo jeito superlegal sobre como gerenciar múltiplas versões 
do Node.js. No próximo capítulo, vamos explorar uma outra ferramenta im- 
portante do Node.js, o NPM (Node Package Manager). Então, continue lendo, 


pois a brincadeira vai começar! 
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Capítulo 3 


Gerenciando módulos com NPM 


31 Oqueéeoquefaz o NPM? 


Fig. 3.1: Logo do NPM 


Assim como o RubyGems do Ruby ou o Maven do Java, o Node.js também 


possui seu próprio gerenciador de pacotes, que se chama NPM (Node Pac- 





kage Manager). Ele se tornou tão popular pela comunidade que, desde a ver- 
sao 0.6.X do Node.js, ele foi integrado no instalador principal do Node.js, 
tornando-se o gerenciador padrão desta plataforma. Isto simplificou a vida 


3.2. Principais comandos do NPM Casa do Código 


dos desenvolvedores na época, pois fez com que diversos projetos se conver- 
gissem para esta ferramenta. 





npm 


npm is the package manager for javascript 
6 LE? ss f: | He, 73,387 Ia 552.123, 21 EA 2,343,713, 408 


broust 
pust 


es otoci 'nem instal’ ata 


expres: m 
PM -— 


mpa pre) 








Fig. 3.2: Homepage do NPM 


Atualmente, o site https://npmjs.org hospeda mais de 213.000 módulos 
Node.js criados por terceiros e comunidades. Diariamente são efetuados mais 
de 120 milhões de downloads e, mensalmente, são cerca de +2.9 bilhões de 
downloads de diversos módulos. 


32 Principais comandos do NPM 


Utilizar o NPM é muito fácil. Suas utilidades vão além de um simples ge- 
renciador de dependência, pois ele permite também que você crie comandos 





de automatização de tarefas para seus projetos que são declarados, por meio 
do arquivo Package.json, A seguir, veja os principais comandos e seus 
respectivos significados: 


e npm INIT; exibe um miniquestionário para auxiliar na criação e des- 
crição do package.json do seu projeto; 
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e npm install nome do módulo: instala um módulo no projeto; 


e npm install -g nome do módulo: instala um módulo global; 


e nom install nome do módulo --save: instala o módulo 


e adiciona-o no arquivo Package.json, dentro do atributo 
"dependencies": 


e nom install nome do módulo --save-dev:. instala o módulo 


e adiciona-o no arquivo Package.json, dentro do atributo 
"devDependencies": 


e npm list: lista todos os módulos que foram instalados no projeto; 
e nom list -9: lista todos os módulos globais que foram instalados; 
e npm remove nome do módulo: desinstala um módulo do projeto; 


e npm remove -g nome do módulo: desinstala um módulo global; 


e npm remove nome do módulo --save. desinstala um módulo 


do projeto, removendo também do atributo dependencies" do 
package.json: 


e nom remove nome do módulo --save-dev: desins- 


tala um módulo do projeto, removendo também do atributo 
"devDependencies" do package.json: 


e npm update nome do módulo: atualiza a versão de um módulo do 


projeto; 


e npm update -g nome do módulo: atualiza a versão de um mó- 


dulo global; 
e npm -V: exibe a versão atual do NPM; 


e npm adduser nome do usuário: cria um usuário no site https:// 


npmjs.org; 


e npm whoami: exibe detalhes do seu perfil público NPM do usuário (é 


necessário criar um usuário com o comando anterior); 
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e npm publish: publica um módulo no https://npmjs.org (é necessário 
ter uma conta ativa primeiro); 


e nom help: exibe em detalhes todos os comandos. 


33 Entendendo o package.json 


Todo projeto Node.js é chamado de módulo. Mas, o que é um módulo? No 
decorrer da leitura, perceba que falarei muito sobre o termo módulo, biblio- 
teca e framework e, na prática, eles significam a mesma coisa. 

O termo módulo surgiu do conceito de que o JavaScript trabalha com uma 
arquitetura modular. E quando criamos um projeto, ou seja, um módulo, este 
é acompanhado de um arquivo descritor de módulos, conhecido pelo nome 
package.json, 

Este arquivo é essencial para um projeto Node.js. Um package.json 
mal escrito pode causar bugs ou até impedir o funcionamento do seu projeto, 
pois ele possui alguns atributos chaves, que são compreendidos tanto pelo 
interpretador do Node.js como pelo comando "pm, 


Para demonstrar na prática, veja a seguir um exemplo de um simples 





package.json, que descreve os principais atributos de um módulo: 


{ 
"name": "meu-primero-node-app", 
"description": "Meu primeiro app Node. js", 
"author": "User «userQemail.com»", 
"version"; "1.2.3", 
"private"; true, 
"dependencies": { 
"modulo-1";: "1.0.0", 
"modulo-2": ""1,0,0", 
"modulo-3";: ">-1,0,0" 
k, 
"devDependencies": 1 
"modulo-4"; "x" 
} 
} 
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Com esses atributos, vocé já descreve o mínimo necessário sobre o que 
será seu módulo. O atributo Name é o principal. Com ele, você define 


o nome do projeto, nome pelo qual seu módulo será chamado via função 
require('meu-primeiro-node-app?), Em description, descreve- 








mos o que será este módulo. Ele deve ser escrito de forma curta e clara, for- 
necendo um resumo sobre o que será. 

O author é um atributo que informa o nome e e-mail do autor. Utilize 
o formato Nome «email» para que sites, como https://npmjs.org, reconhe- 
cam corretamente esses dados. 

Outro atributo principal é o Version, com o qual definimos a ver- 
sáo atual deste módulo. É extremamente recomendado que tenha este atri- 
buto, para permitir a instalação de um módulo via comando nem install 
meu-primeiro-node-app, O atributo Private é opcional, ele é apenas 
um boolean que determina se o projeto será código aberto ou privado. 

Os módulos no Node.js trabalham com 3 níveis de versionamento. Por 
exemplo, a versão 1.2.3 esta dividida nos níveis: 


1) Major 
2) Minor 


3) Patch 





Repare que no campo dependencies foram incluídos 4 módulos, sendo 





que cada um utiliza uma forma diferente de versão. 

O primeiro, o modulo-1, somente será instalado sua versão fixa, a 
1.0.0 Use este tipo de versão para instalar dependências cujas atualizações 
possam quebrar o projeto pelo simples fato de que certas funcionalidades fo- 
ram removidas e ainda as utilizamos na aplicação. 

O segundo módulo já possui uma certa flexibilidade de atualização. Fle 
usa o caractere ~, que permite atualizar um módulo a nível de patch ( 
1.0.x). Geralmente, essas atualizações são seguras, trazendo apenas me- 
lhorias ou correções de bugs. 

O modulo-3 atualiza versões que sejam maior ou iguala 1.0.0 em to- 
dos os níveis de versão. Em muitos casos, usar >= pode ser perigoso, porque 
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a dependéncia pode ser atualizada a um nível major ou minor e, consequente- 


mente, pode conter grandes modificações que podem quebrar a sua aplicação, 
exigindo que você ou atualize seu projeto para ficar compatível com a nova 
versão, ou volte a usar a versão anterior para deixar tudo de volta ao normal. 

O último, o modulo-4 utiliza o caractere *. Este sempre pegará a úl- 
tima versão do módulo em qualquer nível. Ele também pode causar proble- 
mas nas atualizações e tem o mesmo comportamento do versionamento do 
modulo-3. Geralmente, ele é usado em devDependencies, que são de- 


pendências focadas para uso em ambiente de desenvolvimento e testes, em 











que as atualizações neste tipo de ambiente não prejudicam o comportamento 
da aplicação que já se encontra em ambiente de produção. 





Caso você queira ter um controle mais preciso sobre as versões de suas 
dependências após a instalação das dependências de seu projeto, rode o co- 
mando npm shrinkwrap, Eletrava as versões de suas dependências dentro 
do arquivo npm-shrinkwrap.json, de modo que você tenha total controle 
sobre quais versões foram instaladas em seu projeto. Com 1sso, você visualiza 
quais versões estão em seu projeto, inclusive quais versões das dependências 
de suas dependências foram instaladas. Este comando é para uso em ambi- 





ente de produção, onde o controle de versões precisa ser mais rigoroso. 


34 Automatizando tarefas com NPM 


Você também pode automatizar tarefas usando o npm, Na prática, 
você apenas cria novos comandos executáveis por meio do npm run 
nome do comando, Para declarar esses novos comandos, basta criá-los den- 
tro do atributo scripts no package.json, Veja um bom exemplo a se- 


guir: 


{ 
"name"; "meu-primero-node-app", 
"description": "Meu primeiro app Node. js", 
"author"; "User <userQemail.com>", 
"version": "1.2.3", 


"private": true, 
"scripts": ( 


"start": "node app. js", 
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"clean": "rm -rf node modules", 
“test”: "node test. js" 

+, 

"dependencies": ( 
"modulo-1": "1.0.0", 
"modulo-2": " 1.0,0", 
"modulo-3"; "»-1.0.0" 

| 


"devDependencies": { 


"modulo-4"; "ur 





Repare que foram criados 3 scripts: start, clean e test, Estes 
agora são executáveis via seus respectivos comandos: Nem run start, npm 
run clean e npm run test, Como shortcut, somente os scripts start 
e test podem ser executados através dos comandos nem start e npm 
test. Dentro de scripts, você pode executar tanto os comandos node, npm 





quanto qualquer outro comando global existente em seu sistema operacio- 
nal. O npm run clean é um exemplo disso; nele estou executando o co- 


mando rm -rf node modules que, na prática, apaga todo conteúdo da 
pasta node modules, 


Conclusão 


Parabéns! Se você chegou até aqui, então você aprendeu o essencial do 





NPM para gestão de dependências e automatização de tarefas. E de extrema 
importância dominar pelo menos o básico do NPM, pois ele será usado com 
muita frequência no decorrer deste livro. 





Aperte os cintos e se prepare! No próximo capítulo, começaremos o nosso 
projeto piloto de API RESTful, que será trabalhado no decorrer dos demais. 





Como spoiler, vou contar aqui um pouco sobre o que será esse projeto. 

Nos próximos capítulos, será desenvolvido na prática uma API REST de 
um simples sistema de gestão de tarefas. Não só uma API será desenvolvida 
como também vamos criar uma aplicação cliente web que vai consumir os 
dados desse serviço. Todo esse desenvolvimento será realizado utilizando al- 
guns frameworks populares do Node.js, como o Express para web framework; 
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Sequelize para lidar com banco de dados SQL-like; Passport para lidar com 


autenticação de usuários, e muito mais. Continue lendo! 
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Capítulo 4 


Construindo a API 


Agora que temos o ambiente Node.js configurado e pronto para uso, vamos 
explorar na prática a criação de uma simples aplicação do tipo API RESTful. 
Esse tipo de aplicagào está atualmente sendo desenvolvido por muitos proje- 
tos, pois ele traz como vantagem a boa prática de criar uma aplicação focada 
em apenas servir dados para qualquer tipo de aplicação cliente. 

Hoje em dia, é muito comum criar aplicações clientes para web e mobile 
que consomem dados de uma API. Isso faz com que diversos tipos de apli- 
cações cliente consultem um mesmo servidor centralizado e focado a apenas 
lidar com dados. Além disso, também permite que cada aplicação — seja ela 
cliente ou servidor — seja trabalhada isoladamente, por equipes distintas. 

Inicialmente, vamos construir uma API, porém, no decorrer dos capítu- 
los, também vamos construir uma simples aplicações cliente web para con- 
sumir dados da API. Para começar o desenvolvimento da API, usaremos um 
framework web muito popular, que se chama Express. 


4.1. Introduç ão ao Express Casa do Código 


41 Introdução ao Express 


O Express é um framework web minimalista, que foi fortemente inspirado 
pelo framework Sinatra do Ruby. Com ele, você pode criar desde aplicações 
pequenas até grandes e complexas, sem nenhum problema. Esse framework 
permite a construção de APIs e também a criação de aplicações web. 

Seu foco é trabalhar com perfeição manipulando views, routes e 
controllers, ficando à sua escolha trabalhar com models e usar qualquer 
framework de persistência sem gerar nenhum conflito ou incompatibilidade 
com Express. Isso é uma grande vantagem, pois existem muitos módulos do 
tipo ODM (Object Data Mapper) e também ORM (Object Relational Map- 
ping) disponíveis para o Node.js. Você pode usar qualquer um junto com o 
Express sem a necessidade de configurar alguma integração entre ambos, só 
precisará carregar os módulos de persistência dentro dos controllers ou 
routes de sua aplicação. 

O Express permite que o desenvolvimento organize de forma livre os có- 
digos de uma aplicação, ou seja, não existem convenções rígidas neste fra- 
mework, cada convenção pode ser criada e aplicada. Isso torna-o flexível para 
adoção tanto em aplicações pequenas quanto aplicações grandes, pois nem 





sempre é necessário aplicar diversas convenções de organização no projeto 
para uma pequena aplicação. 

Você também pode replicar convenções de outros frameworks. O Ruby 
On Rails é um exemplo de framework repleto de convenções que vale a pena 
replicar algumas de suas caracteristicas. Essa liberdade força o desenvolvedor 
entender a fundo como funciona cada estrutura da aplicação. 
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"Web ApptilcestTions API Pertormance o Rach 


Fig. 4.1: Site do Express 


Em resumo, veja a seguir uma lista das principais características do Ex- 


press: 


* Routing robusto; 


Facilmente integrável com os principais Template Engines; 
* Código minimalista; 
e Trabalha com conceito de middlewares; 


* Possui uma grande lista de middlewares 3rd-party; 


Content Negotiation; 


* Adota padrões e boas práticas de serviços REST. 
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42 Criando o projeto piloto 


Que tal criarmos um projeto na prática? A partir deste capítulo, vamos ex- 
plorar alguns conceitos de como criar uma API REST utilizando alguns fra- 
meworks do Node js. 

Para começar. criaremos um projeto do zero. A nossa aplicação será um 
simples gerenciador de tarefas. que será dividido em 2 projetos: o primeiro 
será uma API servidora dos dados, e o segundo será um cliente web consu- 
midora do primeiro. 

O nosso projeto terá o nome NTask (Node Task) e terá as seguintes fun- 
cionalidades: 


* Listagem de tarefas do usuário; 

* Consulta, cadastro, exclusão e alteração de uma tarefa do usuário; 
* Consulta, cadastro e exclusão de um usuário: 

* Autenticação de usuário; 


* Página de documentação da API. 


Código-fonte do projeto piloto 


Caso você esteja curioso e gostaria de já ir visualizando o código-fonte 
final dos projetos que serão explorados neste livro, você pode acessar um 
desses dois links: 


e NTask-API https://github.com/caio-ribeiro-pereira/ntask-api 


* NTask-Web: https://github.com/caio-ribeiro-pereira/ntask-web 





Nesta aplicação. vamos explorar os principais recursos para se criar uma 
API REST no Node js e, no decorrer dos capítulos, vamos incluir novos fra- 
meworks importantes para auxiliar no desenvolvimento. 
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Para começar, vamos criar o primeiro projeto com o nome ntask-api, 
rodando o seguintes comandos: 


mkdir ntask-api 
cd ntask-api 
npm init 


Responda o questionário do comando Nem init semelhante a este re- 
sultado: 





= ' EIL 
Cub. NEM npa inii 


ILE uè ty will] walk you through creating e pockoge, ! 


IE anly covers Che most commmn items, ond tries to guess sensibls defoults, 


se com help 1509 for defimitive documentation on thèse fie 
ond exoctiy what they do, 
se mem NLIS INE 1 oo vrterenras to 


sõve it os o dopendoncy in the packāäge. jaoi 


Press ^E ot omy time to quit 

name. (ntask-agi J 

verston! (1.0.0) 

description; API de gestão de tarefas 
entry point; AT. TL 


is qul oin 


cuthor; Caio Ii beiro Pereiro 
License: CISC] 


About to write to "isers/ccio/Uocumant s/wor*spnace/ntcsk«op: /packóge. jon: 


name rosk-gpL 
'wersion": "1.9.0", 


'de£cription' "AI de gestão de caretas”, 
“main*: “indox. js", 
'seripcs": | 


tost”: "echo NV Error: mo test specified!” SA quit 


“Tam Ribeiro oreiro“, 


o E ma 


Is this qm” (ves) ves 


[coio:mtask-api] $ 





Fig. 4.2: Descrevendo o projeto com npm init 


No final, será gerado o arquivo package.json com os seguintes cam- 
pos: 
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t 
"name"; "ntask-api", 
"wregelon": "31.0.0", 
"description": "API de gestáo de tarefas", 
"main": "index. js", 
"scripts": ( 
"test": "echo V"Error: no test specified" && exit 1" 
), 
"author": "Caio Ribeiro Pereira", 
"license": "ISC" 


A versão atual do Node.js não tem 100% de suporte ao ES6, porém po- 
demos usar um módulo que emula alguns recursos interessantes para deixar 


nossa aplicação com códigos lindos do ES6/7. Para isso, vamos instalar o mó- 
dulo babel, que é um Transpiler ES6/7 de código JavaScript compatível. ou 
seja, vamos implementar códigos ES6/7 e ele vai se encarregar de converter 
para código JavaScript ESS, caso o Node.js não reconheça nativamente as no- 
vas funcionalidades. 


O Babel também é compatível para JavaScript client-side, tanto que 
nos ültimos capítulos deste livro vamos usá-lo para construir uma apli- 


cação web cliente usando ES6 também. 
Para conhecer melhor esse projeto, acesse seu site oficial: https:// 
babeljs.io. 





Para utilizarmos ao máximo dessas novas funcionalidades do novo Ja- 


vaScript ES6/7, vamos instalar o módulo babel em nosso projeto. Então. 
execute o comando: 


npm install babel --save 


Em seguida, vamos dar uma turbinada no package.json, Primeiro, 
vamos remover os campos license e scripts.test, Por enquanto, eles 
não serão usados em nosso projeto. 
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Depois, incluiremos o campo scripts.start para habilitar o co- 
mando npm start, que será responsável por iniciar nossa API. Esse co- 
mando vai compilar o código ES6/7 e iniciar o sistema, tudo 1sso por meio 
do comando babel-node index.js. Veja a seguir como fica o nosso 
package.json: 


{ 
"name": "ntask-api", 
"vereilog": "1.0.0", 
"description": "API de gestão de tarefas", 
"main": "index. js", 
"scripts": 1 
"start": "babel-node index. js" 
>, 
"author": "Caio Ribeiro Pereira" 
) 


Agora temos uma descrição mínima do nosso projeto, tudo 1sso, no 
arquivo Package.json, Para começar, vamos instalar o framework 


express rodando o seguinte comando: 


npm install express --save 


Com Express instalado, criaremos nosso primeiro código da API. Esse 
código simplesmente vai carregar o módulo express, criar um simples end- 
point GET / via função app-get("/"), e vai iniciar o servidor na porta 
3000 por meio da função app.listen, Para isso, crie o arquivo principal 
index.js, implementando este código: 


import express from "express"; 
const PORT - 3000; 


const app - express(); 
app.get("/", (req, res) -> res, json((status: "NTask API"])); 
app.listen(PORT, () -> console.log(C NTask API = porta $Í(PORT)')); 


Para testar esse código inicial e, principalmente, validar se o esboço da 
nossa API está funcionando, inicie o servidor com o comando: 
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npm start 


Sua aplicação deverá apresentar a seguinte mensagem no terminal: 


"- € BT 


li: WE mpm stors 


» ntusk-apiP1,0.0 start /Users/cato/Documernts /worxspace/node 1s/ntask-api 


> node 000.75 


NTosk APL - porto 1000 





Fig. 4.3: Iniciando API pelo terminal 


Essas mensagens são referentes ao start da API. Em seguida, abra um 





browser e acesse o enderego: http://localhost:3000. 





se nenhum problema acontecer, será exibida uma resposta em formato 
JSON, semelhante a esta figura: 


t'e 


ty rg TOA 


€ Vl! e Dos "e = 


("status"':"NTask API OK!") 


Fig. 4.4: JSON de status da API 


43 Implementando umrecurso estático 


O padrão de desenvolvimento de uma API REST trabalha em cima do con- 
ceito de criação e manipulação de recursos. Esses recursos basicamente são 
entidades da aplicação que são utilizadas para consultas, cadastros, atualiza- 
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ção e exclusão de dados, ou seja, tudo é baseado em manipular os dados de 
um recurso. 

Por exemplo, a nossa aplicação terá como recurso principal a entidade 
tarefas, que será acessado pelo endpoint /tasks, Esta entidade terá al- 





guns dados que descreverão que tipo de informações serão mantidas nesse 
recurso. Esse conceito segue uma filosofia muito parecida com a modelagem 
de dados, a única diferença é que os recursos de API REST abstraem a origem 





dos dados. Ou seja, um recurso pode retornar dados de diferentes fontes, tais 
como banco de dados, dados estáticos e dados de sistemas externos. 

Uma API tem como objetivo tratar e unificar esses dados para, no final, 
construir e apresentar um recurso. Inicialmente, vamos trabalhar com dados 
estáticos, porém no decorrer do livro vamos fazer alguns refactorings para 
adotar um banco de dados. 

Por enquanto, os dados estáticos serão implementados apenas para mol- 
darmos os endpoints da nossa aplicação. Apenas para moldar nossa API, va- 
mos incluir a rota via função app.get('/tasks”). que retornará apenas 
um JSON de dados estáticos via função res.Json(O,. Veja a seguir como 
serão essas modificações no arquivo !Index.Js: 


import express from "express"; 
const PORT - 3000; 


const app - express(); 
app.get("/", (req, res) -> res, json((status; "NTask API"])); 


app.get("/tasks", (req, res) -> 1 
res. json(f 
tasks: [ 
(title: "Fazer compras"), 
(title: "Consertar o pc"), 


app.listen(PORT, () -> console. log('NTask API = porta $[(PORT)')); 
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Para testar esse novo endpoint no terminal, reinicie a aplicação teclando 
CTRL+C ou Control+C (se você estiver utilizando MacOSX) e, em seguida, 
rode novamente o comando: 


npm start 


Atenção 


Sempre faça essa rotina para reiniciar a aplicação corretamente. 





Agora temos um novo endpoint disponível para acessar por meio do en- 
dereço: http://localhost:3000/tasks. Ao acessá-lo, você terá o seguinte resul- 
tado: 


t. —-—. RA m 
é o wars o 4 msn a x 


'“casks"rj('title':'Fazer compras'),('títie":'Consertar o pc"')]) 


Fig. 4.5: Listando tarefas 


Caso você queira que seus resultados retornem um JSON formatado e 
tabulado de forma amigável. inclua no index.js a seguinte configuração: 
app.set("json spaces”, 4);. Veja a seguir onde incluir essa função: 


import express from "express"; 
const PORT - 3000; 


const app - express(); 
app.set("json spaces", 4); 


app.get("/", (req, res) -> res.json((ístatus: "NTask API"J)); 
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app.get("/tasks", (req, res) -> 1 
res. json(f 
tasks: [ 


(title: "Fazer compras"), 
(title: "Consertar o prMy, 


app. listen(PORT, ( -> console.log( NTask API - porta $(PORT)')); 


Agora, reinicie o servidor e veja um resultado mais elegante: 


m - ġwann = 


“tasks”: | 
( 
"title': "Fazer compras 
Fa 
{ 
"titie": “Consertar o pc' 
; 


Fig. 4.6: Listando tarefas com JSON formatado 


44 Organizando o carregamento dos módulos 


De fato, implementar todos os endpoints no index.js não será uma boa 
prática, principalmente se sua aplicação possuir muitos endpoints. Para isso, 
vamos organizar os diretórios e carregamento dos códigos de acordo com suas 
devidas responsabilidades. 

Vamos aplicar em nosso projeto o padrão MVR (Model-View-Router) para 
organizar nossa aplicação de forma bem simplificada. Usaremos o módulo 
consign, que permite carregar e injetar dependências de forma bem simples. 
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Instale-o via comando: 


npm install consign --save 


Com esse módulo instalado, vamos primeiro migrar os endpoints do 
index.js, criando dois novos arquivos de rotas para o novo diretório 
routes. Para isso, crie o código routes/index,js; 


module.exports - app -> { 
app.get("/", (req, res) -> 1 
res. json((status: "NTask API"]); 
)2; 
+; 


E também migre o trecho do endpoint app.get("/tasks”) do ar- 
quivo index.js para o novo arquivo routes/tasks,js: 


module .exports - app -> f 
app.get("/tasks", (req, res) -> ( 
res. json(f 
tasks; [ 
(title: "Fazer compras"), 
(title: "Consertar o pc"), 


Para finalizar essa etapa, edite o index.js, para que ele carregue essas 
rotas por meio do módulo CONSI9N e inicie o servidor: 


import express from "express"; 
import consign from "consign"; 
const PORT - 3000; 

const app - express); 
app.set("json spaces", 4); 


consign() 
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| include ("routes") 
.into(app?); 


app.listen(PORT, () -> console. log('NTask API - porta $(PORT)')); 


Pronto! Acabamos de organizar o carregamento dos endpoints da nossa 
API. Repare que, neste momento, estamos focando apenas em trabalhar com 
o VR (Viewe router) do padrão MVR. Em uma API, os resultados em formato 


JSON são considerados como Views, A próxima etapa é organizar os models, 





Para isso, crie o diretório models e voltando no  index;js, 
altere os parâmetros da função | COnsign( para que primeiro seja 
carregado os models e, depois, os routes, utilizando a função 
consign(.include(^models").then("routes") do mesmo objeto. 
Para ficar mais clara essa modificação, veja a seguir como deve ficar o carre- 
gamento desses módulos: 


import express from "express"; 
import consign from "consign"; 
const PORT - 3000; 


const app - express); 
app.set("json spaces", 4); 


consign() 
| include ("models") 
then('"routes") 
.into(app); 


app.listen(PORT, () -> console.log( NTask API - porta $(PORT)')); 


Neste exato momento, a função COnsign( não vai carregar nenhum 
modelo, inclusive o diretório models não possui nenhum código ainda. Para 
preencher essa lacuna, vamos criar temporariamente um modelo com dados 
estáticos para finalizarmos essa primeira etapa, que é organizar o carrega- 
mento dos módulos internos. 





Para isso, crie o arquivo models/tasks.js e implemente este código: 
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module.exports - app -> f 
return { 
findAll: (params, callback) -> 1 
return callback([ 
(title: "Fazer compras"), 
(title: "Consertar o pc"], 


T3 


E 
ae 


Esse modelo inicialmente terá apenas a função Tasks.findAIO, que 
receberá dois argumentos como parâmetro: params e callback, A va- 
riável params não será utilizada no momento, mas ela servirá de base para 
enviar alguns filtros de pesquisa SQL, algo que será abordado em detalhes nos 
próximos capítulos. Já o segundo argumento é função de callback que retorna 
de forma assincrona um array estático das tarefas. 

Para chamá-lo dentro de routes/tasks.js, você terá de carregar esse 
modelo por meio da variavel APP. Afinal, os módulos dos diretórios inseridos 
na função consign(Q injetam suas lógicas dentro dessa variável principal 
da aplicação. Para ver como funciona na prática, edite o routes/tasks.js 
da seguinte maneira: 


module .exports = app -> 1 
const Tasks - app.models,. tasks; 
app.get("/tasks", (req, res) -> ( 
Tasks.findAll((), (tasks) -> ( 
res.json(Íítasks: tasks)); 
+); 
H; 
); 





Repare que a função Tasks.findAIIO possui no primeiro parâmetro 
um objeto vazio 13. Este é o valor da variável params, em que, neste caso, 
não houve necessidade de incluir parâmetros para filtros na listagem das ta- 
refas. 

O callback dessa função retorna em seu parâmetro a variável tasks que 
foi criada com valores estáticos dentro do modelo models/tasks.js. En- 
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tào, no momento, temos a total certeza de que tasks retornará um array 
estático com as duas tarefas que foram criadas. 

Para finalizar essas modificações, vamos criar um arquivo que carre- 
gará toda a lógica dos middlewares e configurações específicas do Express. 
Atualmente, temos apenas uma simples configuração de formatação JSON, 
que ocorre via função app.set('son spaces”, 4), Vamos incluir 
mais uma configuração que será a porta do servidor chamando a função 
app.set("port", 3000). 

No decorrer do livro, exploraremos novos middlewares e configurações 
para o nosso servidor. Logo, já recomendo desde agora a preparar a casa para 
receber novas visitas! 


Crie o arquivo libs/middlewares.js seguindo esse código: 


module . exports - app -> f 
app.set("port", 3000); 
app.set("json spaces", 4); 


b 


Para simplificar, vamos criar o arquivo libs/boot.js, que será respon- 
sável por iniciar o servidor através da função ap p.listen O, Nele, vamos 
remover a constante PORT para usar a função app-get( port): 


module.exports = app -> { 
app.listen(app.get("port"), O -> 1 
console. log('NTask API - porta $Ííapp.get("port")]'); 
)); 


Para finalizar, vamos carregar por último o libs/boot.js dentro da 
estrutura do módulo consign, Edite novamente o Index.Jjs com as se- 
guintes modificações: 


import express from "express"; 
import consign from "consign"; 


const app - express(); 
consign() 
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, include ("models") 
then("libs/middlewares. js") 
then("routes") 
.then("libs/boot.js") 
,into(app?); 


Para testar essas novas alterações, reinicie seu servidor e acesse nova- 
mente o endpoint: http://localhost:3000/tasks. 


"-* T 
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node index. 75 
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+ imodels/tósks, js 
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Fig. 4.7: Listando modulos carregados 


Parater certeza de que tudo está funcionando corretamente, nenhum erro 





deve ocorrer e todos os dados das tarefas devem ser exibidos normalmente. 


Conclusão 


Parabéns, the mission is complete! No próximo capítulo, vamos incremen- 


tar nosso projeto implementando mais funcionalidades para gerenciar as ta- 
refas de forma dinâmica e usar um banco de dados através do framework 


Sequelize. 
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Trabalhando com banco de 
dados relacional 


5.1 Introdução ao SQLite3 e Sequelize 


No capítulo anterior, criamos uma estrutura inicial de rotas para a nossa API 
realizar uma simples listagem de tarefas utilizando um modelo de dados es- 
táticos. Isso foi o suficiente para explorar alguns conceitos básicos de estru- 
turação de nossa aplicação. 

Agora, vamos trabalhar mais a fundo na utilização de um banco de dados 
relacional, que será necessário para implementar uma gestão dinâmica dos 
dados de nossa aplicação. Para simplificar nossos exemplos, vamos usar o 
banco SQLite3. Ele é pré-instalado nos sistemas operacionais Linux, Unix e 
MacOSX, então não há necessidade de configurá-lo. Entretanto, caso você 


5.1. Introduç ão ao SQLite3 e Sequelize Casa do Código 





utilize o Windows, você pode facilmente instalá-lo seguindo as instruções 
desse link: https://www.sqlite.org/download.htm. 


Wo 


Fig. 5.1: Logo do SQLite3 


O SQLite3 é um banco que armazena todos os dados em um arquivo de 
extensão -Sqlite, Ele possui uma interface de linguagem SQL muito seme- 
lhante aos demais bancos de dados e está presente não só nos sistemas desktop 
como também em aplicações mobile. 

No Node.js, existem diversos frameworks que trabalham com SQLite3. 
Em nossa aplicação, vamos usar o módulo Sequelize, que é um módulo com- 
pleto, e possui uma interface muito bonita e fácil de trabalhar. Nele, será pos- 
sível manipular dados usando (ou nào) comandos SQL, e ele também suporta 
facilmente os principais bancos de dados SQL, tais como: PostgreSQL, Mari- 
aDB, MySQL, SQL Server e SQLite3. 


Sequelize 





Fig. 52: Logo do Sequelize 





O Sequelize é um framework Node.js do tipo ORM (Object Relational 
Mapper). Suas funções são adotam o padrão Promises, que é uma implemen- 
tação semântica para tratamento de funções assíncronas presente no ECMAS- 
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cript 6 do JavaScript. 
Atualmente, ele está na versào 3.8.0 e possui funcionalidades para trata- 





mento de transações, modelagem de tabelas, relacionamento de tabelas, re- 
plicação de bancos para modo de leitura e muito mais. 


Sequelize 





Fig. 5.3: Homepage do Sequelize 


Seu site oficial com a documentação completa é http://sequelizejs.com. 


52 Configurando o Sequelize 


Para começarmos com o Sequelize, basta executar no terminal o seguinte co- 
mando: 


npm install sqglite3 sequelize --save 


Com esses dois módulos instalados, já temos em nosso projeto as depen- 
dências necessárias para nossa APIse conectar em um banco de dados. Agora, 
vamos criar um arquivo de configuração de conexão entre o Sequelize com 
o SQLite3. Para isso, crie o arquivo o libs/config.js com os seguintes 
parâmetros: 
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e database — define o nome da base de dados; 

e username — informa o nome de usuário de acesso; 

e password — informa a senha do usuário: 

e params.dialect — informa qual é o banco de dados a ser usado; 


e params.storage — é um atributo específico para o SQLite3, sendo 
que nele é informado o diretório que será gravado o arquivo da base de 
dados; 


e para ms.define.underscored — padroniza o nome dos campos 
da tabela em minúsculo usando underscore no lugar dos espaços em 


branco. 


Veja a seguir como fica esse arquivo: 


module .exports - 1 
database; "ntask', 


username: "", 
password: "", 
params: 1 


dialect: "sqlite", 
storage: "ntask, sqlite", 
define; { 

underscored: true 


—— 
PE 


Após criar esse simples arquivo de configuração, vamos agora criar o có- 
digo responsável pela conexão com o banco de dados que usará essas confi- 
gurações. Esse código de conexão adotará o design pattern Singleton, ou seja, 
ele vai garantir que seja instanciada apenas uma vez a conexão do Sequelize. 
Isso vai permitir carregar inúmeras vezes esse módulo realizando apenas uma 
única conexão com o banco de dados. 


Para isso, crie o código dÞ-JS da seguinte maneira: 
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import Sequelize from "sequelize"; 
const config - require("./libs/config.js"); 


let sequelize - null; 


module . exports - O) -> { 
if (!sequelize) { 
sequelize - new Sequelize( 
config.database, 
config.username, 
config.password, 
config.params 
); 
) 
return sequelize; 


bs 


Pronto! Para iniciar esse módulo de conexáo, vamos incluí-lo no carre- 
gamento de módulos do consign, O db.js será o primeiro módulo a ser 
executado (por meio da função consignO.include("db.js");), pois 
os demais códigos da aplicação usarão essa Instância de conexão do Sequelize 
para manipulação dos dados. Para implementar isso, edite o index.js; 


import express from "express"; 
import consign from "consign"; 


const app - expressO; 


consign() 
.include("db,.js") 
.then("models") 
.then("libs/middlewares,js") 
.then("routes") 
.then("libs/boot.js") 
.into(app?; 


Para finalizar o setup do Sequelize, vamos implementar uma simples fun- 
ção de sincronização, entre o Sequelize com o banco de dados. Essa sincronia 
realiza, se necessário, alterações nas tabelas do banco de dados, de acordo 
com o que for configurado nos modelos da aplicação. Para incluir a função 
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app.db.sync(, para que sincronize as tabelas do banco de dados com os 
modelos do Sequelize, vamos editar o libs/boot.js baseando-nos no có- 
digo a seguir: 


module.exports - app -> 1 
app.db.sync().done(() -> 1 
app.listen(app.get("port"), O -> { 
console.log( NTask API = porta $[app.get("port"))'); 
n; 
1» a 
) 


Para testar essas modificações, reinicie o servidor. Se estiver tudo certo, 
sua aplicação deverá funcionar do jeito que estava antes, afinal, nenhuma mo- 
dificação visível foi realizada, apenas algumas adaptações foram implementa- 
das para tornar nossa aplicação conectável a um banco de dados. Na próxima 
seção, modificaremos toda a modelagem de dados, e isso sim terá um grande 
impacto nas mudanças. 


53 Modelando aplicação com Sequelize 


Até agora, o único modelo de nossa aplicação, o models/tasks.js, está 
retornando dados estáticos via função Tasks.findAVIl(), Isso foi necessá- 

rio, pois precisávamos, no capítulo anterior, preparar a estrutura de diretórios 
e carregamento dos módulos da aplicação. 


Nesta seção, vamos explorar as principais funcionalidades do Sequelize 





para a criação de modelos que representarão as tabelas do nosso banco de 
dados e os recursos de nossa API. 

Nossa aplicação terá apenas dois modelos: Users e Tasks, O relacio- 
namento entre essas tabelas será de Users 1-N Tasks, semelhante a esta 
figura: 
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1 N 


USUÁRIOS < | >| TAREFAS 





Fig. 5.4: Modelagem da base de dados 


Para trabalhar com esse tipo de relacionamento, usaremos as funções do 
Sequelize: Users.hasMany(Tasks) (no futuro models/users.js) e 
Tasks.belongsTo(Users) (no models/tasks.js). Essas associações 
serão encapsuladas dentro de um atributo chamado classMethods, que 
permite incluir funções estáticas para o modelo. 

Em nosso caso, vamos criar a função associate dentro de um 
classMethods de cada modelo. Assim poderemos executar essa função de 
relacionamento de tabelas dentro do db.js, que será em breve modificado 


para atender essa necessidade. 


Criando modelo Tasks 


Para iniciar essa brincadeira, vamos começar modificando e modelando 


o arquivo models/tasks.js, aplicando as seguintes alterações: 


module .exports - (sequelize, DataType) -> 1 
const Tasks - sequelize.define("Tasks", 1 
id; ( 
type: DataType.INTEGER, 
primaryKey: true, 
autoIncrement: true 
H, 
title: 1 
type: DataType. STRING, 
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allowNull: false, 
validate: { 
notEmpty: true 

} 

k, 

done: (1 
type; DataType.BOOLEAN, 
allowNull: false, 
defaultValue: false 


} 
E. 9 
classMethods: { 
associate: (models) -> 1 
Tasks .belongsTo(models.Users); 
) 
) 
)5; 
return Tasks; 


+; 


A função Sequelize.define( Tasks") é responsável por criar ou 
alterar uma tabela no banco de dados. Isso ocorre quando o Sequelize faz 
uma sincronização no Doot da aplicação. Seu segundo parámetro é um objeto, 
e seus atributos representam respectivamente os campos de uma tabela, e seus 
valores são subatributos descritores do tipo de dados desses campos. 

Neste modelo, o campo İd é do tipo inteiro ( DataType.INTEGER), Ele 
representa uma chave primária ( PrimaryKey: true) e seu valor é autoin- 
cremental (autolncrement: true) a cada novo registro. 

O campo title é do tipo String ( DataType.STRING), Nele foi 
incluído o atributo allowNull: false para nào permitir valores nu- 
los, e também um campo validador, que verifica se a string nào é va- 
zia ( Validate.notEmpty: true), O campo done é do tipo boo- 
lean ( DataType. BOOLEAN), que não permite valores nulos ( allow Null: 
false). Aliás, se não for informado um valor para este campo, ele será por 
padrão registrado como false ( defaultValue: false), 

Por último, temos um terceiro parâmetro que permite incluir funções es- 
táticas encapsulados dentro do atributo classMethods, Nele foi criada a 


46 


Casa do Código Capítulo 5. Trabalhando com banco de dados relacional 


função associate(models). que vai permitir realizar uma associação en- 
tre os modelos. Neste caso, o relacionamento foi estabelecido por meio da 


função Tasks.belongsTo(models.Users). Esse é um relacionamento 
do tipo Tasks 1-N Users, 


Atenção 


Ainda não foi criado o modelo Users. Então, se você reiniciar o 
servidor, um erro acontecerá. Fique tranquilo e continue lendo para fi- 
nalizarmos a modelagem de nossa aplicação. 





Criando modelo Users 


Para completar nossa simples modelagem, vamos criar o modelo 


que vai representar os usuários de nossa aplicação. Crie o arquivo 
models/users.js com as seguintes definições: 


module . exports = (sequelize, DataType) -> 1 
const Users - sequelize.define("Users", { 
id: ( 
type: DataType.INTEGER, 
primaryKey: true, 
autoIncrement: true 
), 
name: ( 
type: DataType.STRING, 
allowNull: false, 
validate: { 
notEmpty: true 
) 
), 
email: 1 
type: DataType.STRING, 
unique: true, 
allowNull: faise, 
validate: { 
notEmpty: true 
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}, 1 
classMethods: { 
associate: (models) -> { 
Users.hasMany(models.Tasks); 


) 
)2; 
return Users; 


js 


Dessa vez, a modelagem dos campos da tabela Users foi muito se- 
melhante ao modelo lasks, A única diferença foi a inclusão do atributo 
unique: true, dentro do campo email, para garantir que nào cadastrem 
e-mails repetidos neste campo. 

Após terminar essa etapa de modelagem, vamos agora alterar alguns có- 
digos existentes no projeto, para que eles possam carregar corretamente esses 
modelos e executar suas respectivas funções de relacionamento entre tabe- 
las. Para começar, vamos modificar no index.js o carregamento de alguns 
módulos. 

Em primeiro lugar, vamos ordenar o carregamento dos módulos para que 
o libs/config.js carregue primeiro e, em seguida, o db.js. Também 
vamos remover o carregamento do diretório models do consig. Vejacomo 
o código deve ficar: 


import express from "express"; 
import consign from "consign"; 


const app - express(); 


consign() 
| include ("libs/config. js") 
.then("db. js") 
.then("libs/middlewares. js") 
.then("routes") 
.then("libs/boot.js") 
,into(app); 
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O motivo da exclusão do diretório models via módulo consign é que 
implementaremos todo o carregamento dos modelos diretamente pelo ar- 
quivo db.js, por meio da função sequelize.import(, Afinal, se você 
voltar nos códigos dos modelos, perceberá que surgiram dois novos atributos 
dentro de module.exports = (sequelize, DataType). Estes serão 
magicamente injetados via função sequelize.import, que é responsável 


por carregar e definir os modelos no banco de dados. Praticamente, faremos 
o seguinte refactoring no código cb Js: 


import fs from "fs"; 
import path from "path"; 
import Sequelize from "sequelize"; 


let db - null; 


module,.exports - app -> 1 
if (!db) 1 

const config - app. libs.config; 

const sequelize - new Sequelize( 
config. database, 
config.username, 
config.password, 
config.params 

25 

db = { 
sequelize, 
sequelize, 
models: () 

+; 

const dir - path. join(. dirname, "models"); 

fs.readdirSync(dir),.forEach(file -> 1 
const modelDir - path. join(dir, file); 
const model - sequelize, import (modelDir); 
db. models [model name] - model; 

p; 

Übject.keys(db.models).forEach(key -> 1 
db.models[key].associate(db.models); 

DE 
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) 
return db; 


Is 


Dessa vez, o código ficou um pouco complexo, não é ver- 
dade? Porém, sua funcionalidade ficou bem legal! Agora pode- 
mos utilizar as configurações de banco de dados através do objeto 
app.libs.config, Outro detalhe está na execução da função enca- 
deada —Xfs.readdirSync(dir).forEach(file), que basicamente 
vai retornar um array de strings referente aos nomes de arquivos exis- 
tentes no diretório models, Depois, esse array será iterado, para que 
dentro de seu escopo de iteração sejam carregados todos os modelos 
via função sequelize.import(modelDir) e em seguida, inseri- 
dos nesse modelo dentro da estrutura db.models por meio do trecho 
db.models[model.name] = model, 

Após carregar todos os modelos, uma nova iteração ocorre através da fun- 
ção Object.keys(db.models).forEach(key). Ela basicamente exe- 
cutará a função db.models[key].associate(db.models) para garan- 
tir o relacionamento correto entre os modelos. 

Para terminar as adaptações, ainda temos de fazer uma simples al- 


teração no código libs/boot.js, mudando a chamada da função 
app.db.sync( para app.db.sequelize.sync(): 


module.exports - app -> ( 
app.db.sequelize.sync().done(() -> 1 
app.listen(app.get("port"), O -> 1 
console.log( NTask API = porta $[app.get("port"))'); 
n; 
)); 
) 


Em seguida, edite o routes/tasks.js para que ele carregue o modelo 
corretamente pela chamada app.db.models.Tasks, e modifique a função 
Tasks.findAIIO para o padrão promises do Sequelize. Veja a seguir como 


fica: 





module .exports = app -> 1 
const Tasks - app.db . models. Tasks; 
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app.get("/tasks", (req, res) -> 1 
Tasks.findAll([)).then(tasks -> 1 
res, json(ftasks: tasks)); 


Conclusão 


Finalmente terminamos essa adaptação do Sequelize em nossa aplicação. 
Para testar se ela foi corretamente implementada, basta reiniciar o servidor, e 
você verá no terminal (ou prompt de comandos) uma mensagem semelhante 
a esta: 


"TATI TANILI ti AE LISTS 
VARCHARCZSS) UNIQUE 


"Lr lae lisers 9 
PRA MA INDEX Ei Tw LITE Te ITIN! EI 
CREATE TAM IE IF NOT EXISTS 


done BSLISLIFSBER, GM SES 
TC MEME LIEZ72 VEFEDENCES “Users 
Ar TNIEX. LIST Tasks 





Fig. 5.5: Criação das tabelas no banco de dados 


Se você acessar o endereço http://localhost:3000/tasks, dessa vez retor- 


nará um objeto JSON sem tarefas. 
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Fig. 5.6: Agora, a lista de tarefas está vazia! 


Mas não se preocupe, pois no próximo capítulo será implementado os 


principais endpoints para realizar um CRUD completo. Então, keep reading! 
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Capítulo 6 


Implementando CRUD dos 
recursos da API 


Neste capítulo, vamos explorar a fundo o uso de novas funções do Seque- 
lize e também algumas técnicas de organização de rotas e middlewares do 


Express. Implementaremos praticamente um CRUD (Create, Read, Update, 
Delete) dos modelos las ks e Users. 


61 Organizando rotas das tarefas 


Para começar esse lefactoring ^ vamos explorar os principais mé- 


todos do HTTP para CRUD. Neste caso, usaremos as funções 
app.route("/tasks") e  app.route("/tasks/:id") para defi- 


nir dois endpoints: "/tasks" e "/tasks/(id. da task)". 


6.1. Organizando rotas das tarefas Casa do Código 


Essas funções permitirão, por meio de funções encadeadas, o reúso des- 


ses endpoints através das outras funções do Express, que são referentes aos 


métodos do HTTP. Com 1sso, poderemos usar as funções: 





app.allO: é um middleware que é executado via qualquer método 
do HTTP; 


app.get0: executa o método GET do HTTP, ele é usado para con- 
sultas no sistema e, geralmente, retorna algum conjunto de dados de 
um ou múltiplos recursos; 


app.post(0: executa o método POST do HTTP ele é semanticamente 


usado para cadastrar novos dados em um recurso; 


app.putO: executa o método PUT do HTTP, muito usado para atu- 
alizar dados de um recurso da API; 


app.patch(: executa o método PATCH do HTTP, possui uma se- 
mântica parecida com o PUT, porém seu uso é recomendado apenas 
para atualizar alguns atributos de um recurso, e não todos os dados 
dele; 


app.delete(): executao método DELETE do HTTP assim como seu 


nome diz, ele é usado para excluir um determinado recurso da API. 


Para entender melhor o uso dessas rotas, vamos editar 


routes/tasks.Js, aplicando as funções necessárias para estruturar 
um CRUD de tarefas: 


module .exports - app -> 1 
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const Tasks = app.db . models. Tasks; 


app.route("/tasks") 
.all((req, res) -> { 


Middleware de pre-execucáo das rotas 


+) 
get((req, res) -> 1 


tasks! Lista tarefas 


O 
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}) 
post((req, res) -> { 
"tasks"; Cadastra uma nova tà 
)2; 
app.route("/tasks/;:id") 
.all((req, res) -> ( 
Middleware de pre-execucáo das 
) 
.get( (req, res) -> ( 
"/taska/1": Consulta uma taraf 
+) 
put((Greq, res) -> ( 
"/tasks/1"; Atualiza uma taref 
}) 
.delete((req, res) -> { 
"/tasks/1";: Exclui uma tarefa 


}); 
f; 


| 
H 
Lt 


Com essa estrutura mínima, já temos um esboço das rotas necessárias 
para gerenciar tarefas. Agora, podemos implementar suas respectivas lógicas 


para tratar corretamente cada ação do nosso CRUD de tarefas. 


6.2 


Implementando umsimples middleware 


Nos dois endpoints ( /tasks e /tasks/id) teremos de tratar algumas re- 
grinhas no middleware a p p-allO para evitar problemas de acesso no envio 


do atributo 1C de uma tarefa. Esse tratamento será uma regra bem simples, 


veja a seguir como deve ficar: 


app.route("/tasks") 
,all((req, res, next) -> ( 
delete req.body.id; 
next (; 
+) 
Continuação dos ro 
app.route("/tasks/:id") 


ILEIS, 


all((reg, res, next) -> ( 
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delete req.body.id; 
next (); 


+) 


a - - — E ism D . dim E 
Lontrinuacao dos rounuterez 


Praticamente, estamos garantindo a exclusão do atributo Id dentro do 
corpo de uma requisição, ou seja, não será permitido o req.body.id 
nas requisições. Isso porque, nas funções de cada requisição, usaremos 





o req.body como parâmetro das funções do Sequelize, e o atributo 
req.body.id poderá sobrescrever o id de uma tarefa, por exemplo, no 
update oy create de uma tarefa. 


Para finalizar o middleware, avisando-o que deve executar uma função 





respectiva a um método do HTTP, basta incluir no final do callback a fun- 
ção Next() para ele avisar ao roteador do Express que ele pode executar a 
próxima função da rota ou um próximo middleware abaixo. 


63 Listando tarefas via método GET 


Já temos um simples middleware de tratamento para o recurso /tasks, 
agora vamos, por partes, implementar suas funções de CRUD. Para come- 
car, implementaremos a função app-get0, que listará dados do modelo 
Tasks do Sequelize, executando a função Tasks.findAIlO: 





app.route("/tasks") 
.all((req, res, next) -> 1 
delete req.body.id; 
next (); 
}) 
.get((req, res) -> { 
Tasks . findA11(1()) 


.then(result -> res,json(result)) 
.catchCerror -> ( 

res. status(412), json((msg: error.message)); 
B 


+) 


Nesta primeira implementação, vamos listar todas as tarefas do banco por 
meio da execução: Tasks.findAII(()). Apesar de ser uma má prática lis- 
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tar todos os dados por questóes didáticas, vamos deixá-la assim. Mas fique 
tranquilo que no decorrer dos capítulos serào implementados alguns argu- 
mentos nessa função para garantir uma listagem mais específica das tarefas. 

O resultado da consulta ocorre por meio da função then( e, caso exista 
algum problema nela, você pode tratar os erros através da função catch Q0. 
Outro detalhe são os status do HTTP a serem usados, pois uma resposta de 
sucesso retornará por default o status 200 - OK Em nossa APL vamos usar 
o status 412 - Precondition Failed para retornar os demais erros de 
validação de campo, ou erros de acesso na base de dados. 


Sobre os status do HTTP 


Não há uma regra rígida a ser seguida na definição dos status do 
HTTP, porém é recomendável que se entenda o significado dos principais 


status para tornar os status de resposta mais semântico. 

Para conhecer os demais status do HTTP, recomendo a leitura 
desse link oficial do site W3: http://www.w3.org/Protocols/rfc2616/ 
rfc2616-sec10.html 





6.4 Cadastrando tarefas via método POST 


Não há muito segredo na implementação do método POST. Vamos basica- 
mente usar a função Tasks.create(req.body) e, em seguida, tratar seus 
resultados. 

O mais interessante do Sequelize é que sua modelagem já faz uma limpeza 
dos parâmetros que não fazem parte do modelo. Isso é muito bom, pois caso o 
req.body contenha diversos atributos que não foram definidos para o mo- 
delo, eles serão descartados na hora da inserção da tarefa. O único problema 
é a possível existência do atributo req.body.id, que poderia adulterar o 
mecanismo de !d autoincremental do banco de dados. Entretanto, isso já 
foi tratado no middleware da função app-allO, e o resultado de sucesso 
retorna o próprio objeto da tarefa criada. A implementação dessa rota fica da 
seguinte maneira: 
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app.route("/tasks") 
all((req, res, next) -> 1 
delete req.body.id; 
next (); 
+) 
get((req, res) -> 1 
Tasks . findA11(1)) 
.then(result -> res, json(result)) 
.catchlerror -> { 
res. status (412). json((msg: error .message)); 
33; 
}) 
post((req, res) -> { 
Tasks . create (req .body) 
.then(result -> res.json(result)) 
,catchCerror -> 1 
res. status(412). json((msg: error .message)); 
)); 
H; 


6.5 Consultando uma tarefa via método GET 


Já finalizamos as funções do endpoint /tasks, agora vamos tratar as do 
/tasks/:id, Para isso, vamos começar com a implementação da função 
app.route("/tasks/:id"), que também terá a mesma lógica de mid- 
dleware da função - all O anterior. 

Para finalizar, usaremos a função lasks.findOne((where: 
reg.params)), que executará, por exemplo, l'asks.findOne((where: 
(d: "1"33). Elafazuma consulta unitária de tarefas baseada no seu 1d do 
banco de dados e, caso não exista uma tarefa, vamos responder utilizando o 
status 404 - Not Found do HTTP via função res.sendStatus(404), 


que significa que nada foi encontrado. Veja como fica: 


app.route("/tasks/:id") 
all((req, res, next) -> 1 
delete req.body.id; 
next (); 


}) 
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.get((req, res) -> ( 
Tasks.findOne ((where; req.params]) 
,then(result -> 1 
if (result) ( 
res, json(result); 
+ else 1 
res, sendStatus (404); 
) 
}) 
.catch(error -> { 
res. status (412) .json({msg: error.message)); 
H; 
+) 


6.6 Atualizando umatarefa com método PUT 


Agora vamos implementar a função para atualizar uma tarefa na base de da- 
dos. Para isso, não há segredos, basta utilizar a função Task.update), 
cujo primeiro parâmetro você inclui um objeto com dados a serem atualiza- 
dos e, no segundo, um objeto com dados de consulta das tarefas que serão 
atualizadas. Essa função retorna um simples array com um número de atua- 
lizações realizadas na base. 

Mas esse dado não será de grande utilidade para nossa aplicação. Va- 
mos forçar uma resposta de status 204 - No Content por meio da função 
res.sendStatus(204) que significa que a requisição teve sucesso, porém 
não retornou conteúdo como resposta. Veja como fica essa implementação: 


app.route("/tasks/:id") 
all((req, res, next) -> ( 
delete req.body.id; 
next(); 
}) 
get((req, res) -> { 
Tasks .find0ne ((where: req.params]) 
then(result -> { 
if (result) { 
res.json(result); 
) else 1 
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res.sendStatus(404); 


) 
}) 
.catch(error -> { 

res. status (412). json((msg: error .message}); 
H; 


}) 
.put((req, res) -> 1 
Tasks.update(req.body, (where: req.params)) 
then(result -> res.sendStatus(204)) 
.catch(error -> 1 
res, status(412)., json((msg: error message); 

)2; 

+) 


Assim como a função Tasks.create, Tasks.update faz uma lim- 
peza dos campos que não existem no próprio modelo, então não há problemas 
em enviar o 'eq.body diretamente. 


6.7 Excluindo uma tarefa com método DELETE 


Para finalizar, temos de implementar a função de exclusão de tarefas, e mais 
uma vez não há segredos aqui! Basta utilizar a função Tasks.destroy() 

e passar em seu argumento um objeto com dados para consultar qual ta- 
refa será excluída. Em nosso caso, vamos passar o reg.params.id 
para implementar uma exclusão unitária das tarefas e, como resposta de 


sucesso, também será usado o status 204 - No Content, via função 
res.sendStatus(204). Veja como fica: 


app.route("/tasks/;id") 
,all((req, res, next) -> ( 
delete req.body.id; 
next O; 
+) 
get((req, res) -> ( 
Tasks.findÜne((where: req.params)) 
then(result -> 1 
if (result) ( 
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res.json(result); 
) else { 
res.sendStatus(404); 
) 
+) 
.catch(error -=> 1 
res. status(412). json((msg: error messages); 
HDs 
}) 
.put((req, res) -> ( 

Tasks . update (req .body, (where: req.params)) 
.then(result -> res.sendStatus(204)) 
,catch(error -> { 

res.status(412). json((msg: error .message}); 
Hs 
H) 
.delete((req, res) -> { 
Tasks destroy ((where: req.params)) 
.then(result => res.sendStatus(204)) 
.catch(error -> { 
res.status(412),.json(Íímsg: error.message]); 
Tir 
)); 





E assim terminamos a implementação do CRUD de tarefas em nossa API. 


68 Refactoring no middleware 


Para evitar duplicidade de código, aplicaremos um simples refactoring mi- 
grando a lógica repetida da função  app-allO para um middleware 
do Express, por meio do uso da função | app-useQ no arquivo 
libs/middlewares,js, Para aplicar esse refactoring, primeiro ainda no 
arquivo routes/tasks.js, remova as funções ap p-.allO, deixando o 


código com a seguinte estrutura: 


module. exports - app -> f 
const Tasks - app.db. models. Tasks; 
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app.route("/tasks") 
.get((req, res) -> { 
/ Logica do GET /tasks 


p» 
post((req, res) -> 1 

// Logica do PUST /tasks 
n; 


app.route("/tasks/:id") 
.get((req, res) -> ( 
/ Logica do GET /Lasks/1 
+) 
.put((req, res) -> 1 
// Logica do PUT /Lasks/1 
) 
.delete((req, res) -> { 
/ Logica do DELETE /Lasks/1 
HD; 


Após enxugar esse código, abra e edite o libs/middlewares.js, e 
inclua no final dos middlewares a lógica de exclusão do req.body.id: 


import bodyParser from "body-parser"; 
module.exports - app -> { 
app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(bodyParser.json()); 
app.use((req, res, next) -> ( 
delete req.body.id; 
next (); 
HD; 


Dessa forma, evitamos duplicidade de código, centralizando-a em um 
middleware global do Express. 
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6.9 Implementando rotas para gestão de usuá- 
rios 


Também temos de criar as rotas para gestào básica de usuários, afinal, sem 
eles, nào será possível gerenciar tarefas, não é? 

Nosso CRUD de usuários não terá nenhuma novidade. Na verdade, 
ele não será exatamente um CRUD completo, pois ele terá as lógicas para 
cadastrar, buscar e excluir um usuário, não será necessário usar a função 
app.route(), Cada rota será chamada diretamente por seu respectivo mé- 





todo do HTTP. Seu código seguirá o padrão de roteamento semelhante ao de 
tarefas. 
Para codificá-lo, crie o arquivo routes/uUsers.js, com o seguinte có- 


digo: 


module.exports - app -> 1 
const Users ~ app.db.models.Users; 


app.get("/users/:id", (req, res) -> { 

Users.findById(req.params.id, { 
attributes: ["id", "name", "email"] 

}) 

.then(result -> res, json(result)) 

.catch(error -> ( 
res.status(412).json(ímsg: error.message]); 

Hr 

H); 
app .delete("/users/:id", (req, res) -> { 

Users .destroy ({where: {id: req.params.id) )) 
.then(result -> res.sendStatus(204)) 
,catch(error -> { 

res.status(412). json((msg: error.message]); 
HDs 
MEE 
app.post("/users", (req, res) -> 1 

Users.create(req.body) 

.then(result -> res.json(result)) 
.Ccatch(error -> 1 
res. status(412), json((msg: error .message)); 
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H); 
Es 


O motivo de não usarmos a função 8pp.route() nas rotas do recurso 
usuário é que, no próximo capítulo 7, vamos modificar alguns pontos espe- 
cíficos de cada rota, para consultar ou excluir somente o usuário logado no 
sistema, por exemplo. 


610 Testando rotas com Postman 


Para testar essas modificações, reinicie a aplicação, abra o browser e utilize 
algum aplicativo cliente REST, pois será necessário para testar os métodos 
POST, PUT e DELETE. Para simplificar, recomendo a utilização do Postman, 
que é uma extensão para Google Chrome muito completo e fácil de usar. 

Para instalá-lo acesse: https://www.getpostman.com. Então, clique no 
botão “Get it now - its free" Após sua instalação, na tela de Apps do Chrome, 
acesse o icone do aplicativo Postman. 


Luc e wt 1 





9! 4 Aplicativo Postman 


Postera 





Fig. 6.1: Postman Rest Client 


surgirá uma tela para fazer login, porém vocé nào precisa fazer login no 
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Casa do Código 


sistema. Para pular e ir direto para a tela principal, clique no botão “Go to the 


app" 


ae — Clique aqu 


Fig. 6.2: Abrindo o Postman 


Para testar os endpoints, realize os seguintes testes: 


1) Escolha o método POST com endereço http://localhost:3000/tasks; 


2) Clique no menu Body escolha a opção raw, ealtere o formato Text para 
JSON (application/json); 


3) Crie o JSON (C title": "Durmir"} e clique no botão Send; 


4) Modifique o mesmo JSON para {" title": "Estudar^j e clique no- 


vamente no Send; 
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Fig. 6.3: Cadastrando tarefa “Trabalhar” 
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Fig. 6.4: Cadastrando tarefa ‘Estudar’ 


Com esse procedimento, você cadastrou duas tarefas, e agora é possível 


explorar as outras rotas de gestão de tarefas. Para testar os demais endpoints, 


você pode seguir essa simples lista: 


Método GET, rota http://localhost:3000/tasks. 
Método GET, rota http://localhost:3000/tasks/1. 
Método GET, rota http://localhost:3000/tasks/2. 


Método PUT, rota http://localhost:3000/t 


"Trabalhar" 


Método DELETE, rota http://localhost:3000/tasks/2. 


asks/1, body ('title": 


Você também pode testar as rotas de usuários, se quiser. Você pode seguir 


essa simples bateria de testes: 
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e Método POST, rota http://localhost:3000/users, body ft name: 
"John", "email": "john connor.net", "password": 


"123"}. 


e Método GET, rota http://localhost:3000/users/1. 


e Método DELETE, rota http://localhost:3000/users/1. 


Conclusão 





Parabéns para você que chegou até aqui vivo! Já temos um esboço signifi- 
cativo de uma API RESTful, ou seja, já é possível construir aplicações cliente 
para consumir os recursos, tarefas e usuários. 

Continue lendo, pois no próximo capítulo vamos implementar funciona- 
lidades importantes sobre autenticação de usuários em nossa API. See ya! 
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Autenticando usuários na API 


Nossa API já tem um CRUD de tarefas que, graças ao framework Sequelize, 
está integrado a um banco de dados SQL — no nosso caso, o SQLite3. Jáimple- 





mentamos também suas rotas por meio das principais funções de roteamento 
e middlewares do framework Express. 

Neste capítulo, vamos explorar os principais conceitos e implementações 
de autenticação de usuários na API. Afinal, esta é uma etapa importante e ne- 
cessária para garantir que os usuários gerenciem suas tarefas com segurança 
na aplicação. 


11 Introdução ao Passport eJWT 


7.1. Introduç ão ao Passport e JWT Casa do Código 


Sobre o Passport 


Existe um módulo para Node.js muito bacana e fácil de trabalhar com auten- 


ticações de usuário, seu nome é Passport. 





O Passport é um framework extremamente flexível e modular. Ele per- 
mite trabalhar com as principais estratégias de autenticação: Basic & Digest, 
OpenID, OAuth, OAuth 2.0 e JWT. Etambém permite trabalhar com auten- 
ticação via serviços externos, como por exemplo, autenticação por Facebook, 
Google+, Twitter e muito mais. Aliás, em seu site oficial, existe uma lista com 
+300 estratégias de autenticações, que foram criados e adaptados por vários 
desenvolvedores. 


Passi TM 


Simple, unobtrusive authentication for Node.js 


IST WE LT TTE 
I FIORI 


Stratugiem 





Fig. 7.1: Homepage do Passport 


Seu site oficial é http://passportjs.org. 


Sobre o JWT 


O JWT (JSON Web Tokens) é uma estratégia bem simples e segura para 
autenticação de APIs RESTful. Ela é um Open standard para autenticações de 
aplicações web baseado no tráfego de tokens em formato JSON, entre o cliente 
e servidor. Seu fluxo de autenticação funciona da seguinte maneira: 


D Cliente realiza uma requisição uma única vez, enviando suas credenciais 
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2) 


3) 


4) 


3) 


de login e senha; 


Servidor valida as credenciais e, se tudo estiver certo, ele retorna para o 
cliente um JSON com token que encodifica os dados de um usuário logado 
no sistema; 





Cliente, ao receber esse token, pode armazená-lo da maneira que quiser, 
seja via LocalStorage, Cookie ou outros mecanismos de armazenamento 
client-side; 


Toda vez que o cliente acessar uma rota que necessita autenticação, ele terá 
de apenas enviar esse token para a API autenticar e liberar o consumo de 
dados; 


Servidor sempre validará esse token para permitir ou não uma requisição 
de cliente. 


Para detalhes mais específicos sobre o JWT, acesse http://jwt.1o. 


SON Web Tokens are an open, industry standard RFC 7519 method for 
representing claims securely between two parties. 


JWT.IO allows you to decode, verify and generate JWT 





Fig. 72: Homepage do JWT 
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Atenção 


Vamos usar o Passport e JWT em nossa API, afinal, o Passport é um 
módulo muito flexível e poderoso quando o assunto é autenticações de 
usuários. Ele possui uma lista extensa com suporte a +300 diversas es- 
tratégias de autenticação, e o JWT é uma delas também. 

A adoção do JWT é muito viável para o nosso projeto. pois é consi- 
derado um mecanismo leve e prático no tráfego de dados. Afinal, vamos 
trabalhar com tokens em formato JSON, e esse formato já está sendo lar- 
gamente usado em nosso projeto. O JWT é também um mecanismo fácil, 
seguro e sua adoção é muito recomendada para aplicações do tipo API 
RESTful, que é o nosso caso. 





12 Instalando Passport e JWT na API 


Nessa brincadeira, vamos usar os seguintes módulos: 


* Passport: como mecanismo de autenticação: 


* Passport JWT: extensão do JWT para uso como estratégia de autenti- 
cação no Passport: 


* JWT Simple: biblioteca para encodificação/decodificação de tokens do 
JWT. 
Agora instale-os rodando o comando: 


npm install passport passport-jwt jwt-simple --save 


Para começar essa implementação. primeiro vamos adicionar 3 novos 
itens de configuração do JWT. Edite o arquivo libs/config.js e inclua, 
no final, os seguintes atributos: 


module exports - { 
database; “ntask”, 
username: "", 
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password: "", 
params; 1 
dialect; "sqlite", 
storage: "ntask. sqlite", 
define: { 
underscored: true 
} 
k, 
jwtSecret: "Nta$K-AP1", 
jwtSession: (session: false) 
hs 


O campo JWtSecret mantém uma string de chave secreta que servirá 
como base para encode/decode de tokens. E recomendável que essa string seja 
complexa, utilizando diversos caracteres diferentes. 





Jamais compartilhe ou divulgue essa chave secreta em püblico, pois, se 
ela vazar, você deixará sua aplicação vulnerável a invasão, permitindo que 
uma pessoa má intencionada acesse o sistema e gere tokens autenticáveis, sem 
informar as credenciais de login e senha no sistema. 

Para finalizar, o último campo incluído é o JWtSession, que possui 
o objeto (session: false). Esse item será utilizado para informar ao 
Passport que a autenticação não terá sessão de usuário. 


13 Implementando autenticação JWT 


Agora que temos as configurações do Passport e JWT prontas, vamos im- 
plementar as regras de como um cliente será autenticado na aplicação. Para 
começar, implementaremos as regras de autenticação, que também terá fun- 
ções de middlewares do Passport para usarmos nas rotas da API. Esse có- 





digo terá um middleware e duas funções. O middleware será executado no 





momento que ele for carregado na aplicação, e ele basicamente recebe em 
seu callback um Payload, que é um JSON decodificado pela chave secreta 
cfg.jwtSecret, Esse payload terá o atributo Id, que será um id de 
usuário a ser consultado pela função Users.findByld(payload.id), 


Como esse middleware será frequentemente acessado, para evitar Overhead 





na aplicação, vamos enviar um objeto simples contendo apenas o Id e email 
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do usuário autenticado, por meio da função callback: 


done (null, fid; user.id, email; user.email)); 

A lógica dese middleware é injetada via função 
passport.use(strategy). Para finalizar, vamos retornar 2 funções 
do Passport para serem utilizadas no decorrer da aplicação. Elas são as 
funções initialize (inicializa o Passport) e authenticate (usada para 
autenticar acesso a uma rota). 

Para entender melhor essa implementação, crie na pasta raiz o arquivo 
auth.js, com esse código: 


import passport from "passport"; 
import (Strategy) from "passport-jwt"; 


module.exports - app -> 1 
const Users ~ app.db.models.Users; 
const cfg - app.libs.config; 
const strategy - new Strategy([secretÜrKey: cfg.jwtSecret), 
(payload, done) -> ( 
Users.findById(payload.id) 
.then(user -> { 
if (user) { 
return done(null, { 
id: user.id, 
email: user .email 
tig 
} 
return done (null, false); 
) 
.catch(error -> done(Cerror, null)); 
H); 
passport use (strategy); 
return { 
initialize: () -> { 
return passport,.initializeO; 
k, 
authenticate; () -> 1 
return passport ,authenticate("jwt", cfg.jwtSession); 
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j 
}; 


Para carregar o auth.js no início da aplicação, edite o código 
index.js da seguinte maneira: 


import express from "express"; 
import consign from "consign"; 


const app - express); 


consign() 
.include("libs/config. js") 
,then("db. js") 
.then("auth. js") 
then("libs/middlewares . js") 
.then("routes") 
then("libs/boot. js") 
.into(app); 


Para inicializar o Passport no Express, edite o lilbs/middlewares,jse 
inclua o middleware app.use(app.auth.initialize()), Vejaa seguir 


onde incluí-lo: 


import bodyParser from "body-parser"; 
module .exports = app -> { 
app.set("port", 3000); 
app.set("json spaces", 4); 
app . use (bodyParser. json()); 
app . use (app. auth .initialize O); 
app .use((req, res, next) -> 1 
delete reg. body. id; 
next (); 
Hs 
k; 
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74 Gerando Tokens para usuários autentica- 
dos 


Para finalizar a implementação de autenticação JWT em nossa aplicação, va- 
mos agora preparar o modelo Users para criptografia de senha de usuário. 
Também criaremos uma rota para gerar tokens para os usuários que se au- 
tenticarem com seu login e senha no sistema, e faremos um refactoring nas 





rotas de tarefas e usuários para que suas consultas usem corretamente o id 
de usuário autenticado. Com 1sso, finalizaremos essa etapa de autenticação, 
deixando nossa aplicação mais segura e confiável. 

A criptografia de senha dos usuários será realizada pelo módulo bcrypt. 
Para isso, instale-o rodando o comando: 


npm install bcrypt --save 


Agora, vamos editar o modelo Users, Nele incluiremos uma função 
de hooks, que são funções executáveis antes ou depois de uma operação 
no banco de dados. No nosso caso, vamos incluir uma função para ser 
executada antes de cadastrar um novo usuário, por meio do uso da função 
beforeCreate, Vamos utilizar o bcrypt para criptografar a senha do 
usuário antes de salvá-la na tabela de usuários. 

Também será incluída uma nova função dentro de classMethods, Ela 
será usada para comparar se uma senha informada é igual a uma senha crip- 
tografada do usuário. Para codificar essas regras, editeo models/users.js 
com a seguinte lógica: 


import bcrypt from "bcrypt"; 
module exports = (sequelize, DataType) -> { 
const Users - sequelize.define("Users", { 


Os campos desse modelo foram criados no capitulo 


Es 3 
hooks: 1 
beforeCreate: user -> 1 
const salt - bcrypt.genSaltSync(; 
user.password - bcrypt.hashSync(user.password, salt); 
) 
F, 
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classMethods: ( 
associate; models -> { 
Users .hasMany (models, Tasks); 
k, 
isPassword: (encodedPassword, password) -> 1 
return bcrypt.compareSync (password, encodedPassword); 
) 
} 
}35 
return Users; 


+; 


Com essas modificações implementadas no modelo Users, podemos 
agora codificar o novo endpoint /token, Ele será responsável por gerar 
um token encodificado com um payload, dado o usuário que enviar o e- 


mail e senha correto por meio do corpo da requisição (req .body.email e 
req.body.password), 


O payload terá apenas o id de usuário. A geração do token ocorre 
pelo módulo Jwt-simple utilizando sua função Jwt.encode(payload, 
cfg.jwtSecret) que, obrigatoriamente, usará a mesma chave secreta 
jwtSecret, que foi criada no arquivo libs/config.js. Qualquer 


erro gerado nessa rota será tratado através da resposta de status 401 - 
Unauthorized do HTTP, com a função res.sendStatus(401), 


Para incluir essa regra de geração de tokens, crie o arquivo 
routes/token.js com o seguinte código: 


import jwt from "jwt-simple"; 
module.exports - app -> { 
const cfg - app.libs.config; 
const Users - app.db.models.Users; 
app.post("/token", (req, res) -> ( 
if (req.body.email && req.body.password) 1 
const email - req.body.email; 
const password - req.body.password; 
Users.findOne(C(where: (email: email])) 
.then(user -=> ( 
if (Users.isPassword(user.password, password)) 1 
const payload - fid: user id}; 
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res. json(f 
token: jwt.encode(payload, cfg. jutSecret) 
H); 
} else { 
res.sendStatus(401); 
} 
}) 
.catch(error -> res, sendStatus(401)); 
) else { 
res.sendStatus(401); 


Já temos a lógica de autenticação de usuários e também a de validação do 
token. Para finalizar, usaremos a função app.auth.authenticate() que 
valida os tokens enviados pelos clientes e libera (ou não) o acesso a uma de- 
terminada rota da aplicação. Para isso, edite o arquivo routes/tasks.js e 
inclua a função middleware all(app.auth.authenticate()) no início 


das duas rotas. Veja a seguir como fica: 


module .exports - app -> f 
const Tasks - app.db . models. Tasks; 
app.route("/tasks") 
.all(app.auth.authenticate()) 
get((req, res) -> 1 
// Logica do GET /tasks 
+) 
post((req, res) -> f 
// Logica do POST /tasks 
p; 
app.route("/tasks/:id") 
.all(app.auth.authenticate()) 
get((req, res) -> 1 
/ Logica do GET /tasks/1 
) 
put((req, res) -> 1 
// Logica do PUT /tasks/1 
+) 
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.delete((req, res) -> 1 


ogica do DELETE /tasks/1 


p=, 
b 


Kir 


Quando um cliente envia um token válido, o seu acesso a uma rota é au- 
tenticado com sucesso e, consequentemente, surge o objeto Feq-user para 





usá-lo na lógica das rotas. Esse objeto é criado somente quando a lógica do 
auth.js retorna um usuário autenticado, ou seja, somente quando a função 
a seguir retorna um usuário válido: 


Users .findById(payload. id) 


,then(Cuser => { 
if (user) { 
Lembra desáa função” 


3 


return done (null, { 
id: user.id, 
email: user, email 
)); 
) 
return done(null, false); 
+) 


,catch(error -> done(error, null)); 


A função done() envia os dados de usuário autenticado e as rotas au- 
tenticada recebem esses dados através do objeto Feq-user, No nosso caso, 





esse objeto terá apenas os atributos: Id e email, 

Para garantir um acesso correto nos dados do modelo Tasks, vamos fa- 
zer alguns refactorings em todas as funções de acesso à base de dados existen- 
tes nas rotas /tasks e /tasks/:id. Para isso, editeo routes/tasks.js 
e, dentro das rotas de app.route("/tasks”) faça a seguinte modificação: 


app.route("/tasks") 
.all(app.auth.authenticate()) 
get((reg, res) -> 1 
Tasks.findAl1 (1 
where: { user id: req.user. id ) 


}) 
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.then(result -> res.json(result)) 
.catch(error -> ( 
res. status(412), json((msg: error.message]); 
+); 
}) 
.post((req, res) -> { 
req.body.user id - req.user.id; 
Tasks . create(req. body) 
.then(result -> res. json(result)) 
.catch(error -> ( 
res, status(412), json((msg: error.message)); 
H; 
HW 


Ainda no mesmo arquivo, faça as modificações nas queries das rotas in- 
ternas da função app.route("/tasks/:id"): 


app.route("/tasks/:id") 
all (app .auth, authenticate()) 
get((reg, res) -> { 
Tasks. findOne(( where: { 
id; req.params. id, 
user id; req. user, id 
+) 
,then(result -> ( 
if (result) 1 
return res. json(result); 
} 
return res.sendStatus(404); 
}) 
, catcħ(Cerror => { 
res.status(412).json((msg: error .message}); 
p; 
)) 
put((req, res) -> { 
Tasks.update(req.body, ( where: f 
id: req.params.id, 
user id: req. user, id 
HH) 
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.then(result -> res.sendStatus(204)) 
.catch(error -> { 
res .status(412).json({msg: error .message}); 
)2; 
+) 
delete((req, res) -> 1 
Tasks.destroy(( where: { 
id: req.params.id, 
user id: req.user.id 
))) 
.then(result -> res, sendStatus(204)) 
.catch(error -> ( 
res, status(412),json((msg: error.message)); 


Hr 


Para finalizar esse refactoring de acesso aos recursos por meio de usuários 
autenticados, vamos adaptar alguns trechos de código das rotas de usuários. 
Basicamente mudaremos a maneira como se faz uma consulta e exclusão de 





usuário, para que somente seja realizada via 1d do usuário autenticado. 

Então, neste caso, não será mais necessário passar um 1d através do pa- 
râmetro da rota, já que agora a rota /Users/:id será apenas /USer (no 
singular mesmo, pois estaremos lidando com um único usuário logado). So- 
mente a consulta e exclusão terão um middleware de autenticação, logo, am- 
bos poderão se agrupar via função app.route( /user") para usarem o 
middleware da função all(app.auth.authenticate(), No lugar do 
req.params.id, vamos usar req-user.id para garantir que seja usado 
o id de um usuário autenticado. 

Para entender melhor como será essa lógica, edite o arquivo 
routes/users.js e faça as modificações a seguir: 


module. exports = app -> { 
const Users - app.db,. models Users; 
app.route("/user") 
.all(Capp.auth.authenticate()) 
.get( (req, res) -> ( 
Users.findById(req.user.id, { 


attributes: ["id", "name", "email"] 
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}) 
.then(result -> res.json(result)) 
,catch(error -> 1 
res. status(412). json((msg: error .message)); 
H); 
+) 
.delete((req, res) -> 1 
Users. destroy((where: fid: req.user.id) 3) 
.then(result -> res. sendStatus(204)) 
.catch(error -> ( 
res, status(412), json((msg: error messages); 
)); 
p; 
app.post("/users", (req, res) -> 1 
Users.create(req.body) 
then(result -> res, json(result)) 
.catch(error -> ( 
res, status(412), json((msg: error.message)); 
H); 
H; 
>; 


Conclusão 


Parabéns! Finalizamos uma etapa extremamente importante da aplica- 
ção. Dessa vez, os dados das tarefas serão consultados corretamente por um 
usuário autenticado na aplicação. Graças ao JWT, foi possível implementar 





um mecanismo de autenticação segura, que evita o tráfego frequente de se- 





nhas entre cliente e servidor. 

Até agora, só foi implementado todo o back-end da aplicação, e ainda 
não criamos uma aplicação final que use todo poder de nossa API. Mas fique 
tranquilo, há muitas surpresas boas nos próximos capítulos que vão deixá-lo 
muito feliz, apenas continue lendo! 


82 


Capítulo 8 


Testando a aplicação — Parte | 


81 Introdução ao Mocha 


Criar testes automatizados é algo largamente adotado no desenvolvimento de 
sistemas. Existem diversos tipos de testes: unitário, funcional, de aceitação, 
entre outros. Neste capítulo, focaremos apenas no teste de aceitação, que no 
nosso caso visa testar as respostas de sucesso e erros das rotas de nossa API. 





Para criar e executar os testes, vamos usar o TestRunner chamado Mocha, 


que é um módulo muito popular para o Node.js. 


8.2. Configurando ambiente para testes Casa do Código 





Fig. 8.1: Mocha — TestRunner para Node.js 


O Mocha foi possui as seguintes características: 


* Testes no estilo TDD; 

* Testes no estilo BDD; 

* Cobertura de código com relatório para HTML; 
* Resultado dos testes customizado; 

* Teste para funções assíncronas; 


* Facilmente integrado com os módulos Should, assert e chai, 





Praticamente, ele é um ambiente completo para desenvolvimento de testes 
para Node.js. Seu site oficial é https://mochajs.org. 


82 Configurando ambiente para testes 





Para configurarmos nosso ambiente de testes, primeiro configuraremos uma 
nova base de dados que será usada apenas para brincarmos com dados fakes 
pelos testes. Essa prática é largamente utilizada para garantir que uma aplica- 
ção seja facilmente trabalhada em múltiplos ambientes. Por enquanto, nossa 
API possui apenas configurações de um único ambiente, pois até agora, todos 
os exemplos foram desenvolvidos no ambiente de desenvolvimento. 
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Para habilitarmos o suporte a múltiplos ambientes, vamos renomear o 
atual arquivo libs/config.js para libs/config.development.js 
e, em seguida, vamos criar o arquivo libs/config.test.js. O único 
parâmetro novo nesse arquivo éo logging: false, que desabilita os logs 
de comandos SQL no terminal. Será necessário desabilitarmos esses logs para 
nào gerar um report de testes confuso. A seguir, veja como fica esse arquivo: 


module . exports - f 
database: "ntask test", 
username; "", 
password: "", 
params: { 
dialect: "sqlite", 
storage: "ntask.sqlite", 
logging: falso, 
define; { 
underscored: true 
} 
E, 
jwtSecret: "NTALK_TEST", 
jwtSession: (session: false} 


}; 


Agora, temos dois arquivos de configurações, cada qual contém dados es- 
pecíficos para seu respectivo ambiente. Para que a nossa aplicação carregue as 
configurações de acordo com o ambiente, vamos realizar alguns refactorings 





para que ela identifique em qual ambiente ela se encontra. Neste caso, va- 
mos usar o Process.env que basicamente retorna um objeto com diversas 
variáveis de ambiente do sistema operacional. 

Uma boa prática em projetos Node.js é trabalhar com a variável 
process.env.NODE ENV e, com base no seu valor retornado, a nossa 
aplicação terá de carregar configurações para o ambiente test ou 
development (por default, será sempre development, caso o retorno 
dessa variável seja nula ou uma string vazia). 

Com base nisso, recriaremos o arquivo libs/config.js para que ele 
carregue a configuração de acordo com o valor da variável de ambiente do 
sistema operacional. Veja como deve ficar: 
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module.exports - app -> { 
const env ~= process.env.NO0DE ENV; 
if (Boolean(env)) (1 
return require('./config.$fenv).js'); 
) 
return require("./config.development.js"); 


Ps 





Em nosso projeto, vamos explorar apenas a criação de testes de aceitação, 
que serão testes em cima do comportamento e resultado dos endpoints da 
API. Para a criação deles, usaremos os módulos mocha para rodar os testes; 
chai para utilizar uma interface BDD nos testes; e supertest para realizar 
requisições na API. 

Todos esses módulos serão instalados como um devDependencies no 
package.json, para usá-lo apenas como dependência de desenvolvimento 
e testes. Isso você faz usando a flag -- Save-dev, Veja o comando a seguir: 


npm install mocha chai supertest --save-dev 


Agora, vamos encapsular a execução do mocha por meio do comando 





npm test, para que ele execute internamente o comando NODE ENV-test 


mocha test/ **/* js. Para implementar esse novo comando, edite o 
package.json: 


1 
"name"; "ntask-api", 
"version": "1.0.0", 
"description": "API de gestão de tarefas", 
"main": "index, js", 
"scripts": ( 
"start": "babel-node index.js", 
"test": "NODE ENV-test mocha test/**/*, js" 
E. 
"author": "Caio Ribeiro Pereira", 
"dependencies": 1 
"babel": ""5.8.23", 


"bcrypt": "^0,8.5", 
"body-parsaer": "^1.13.3", 
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"consign": "^0.1.2", 
"axpresg"; "^4.13.3", 
"jwt-simple": "70.3.1", 
"passport": ""0.3.0", 


"passport-jwt"; "71.2.1", 
"sequelize": "73.9.0", 
"sglite3"; "3.1.0" 

k, 

"devDependencies": { 
"chas"; "13.3.0", 
"mochg": ""2.3,3", 
"supertest": "^1.1.0" 

} 


Em seguida, exportaremos nossa API para que ela seja iniciada ao execu- 
tar os testes com o Mocha. Para fazer isso, basta incluir no final do index.js 
a função module.exports = app, Também vamos desabilitar alguns 
logs gerados pelo módulo consign pelo trecho consign(tverbose: 


false}) para não poluir o report dos testes. 


import express from "express"; 
import consign from "consign"; 


const app - express(); 


consign((verbose: false]) 
,include("libs/config. js") 
.then("db, js") 
.then("auth. js") 
then("libs/middlewares . js") 
.then("routes") 
.then("libs/boot,js") 
.into(app); 


module.exports = app; 


Agora, a aplicação será iniciada internamente pelo módulo Supertest, 
Para evitar que o servidor inicie duas vezes em ambiente de testes, va- 
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mos modificar o libs/boot.js para que não seja iniciada quando 
process.env. NODE ENV estiver com valor "test" 


Para alterar isso, edite o libs/boot.js com esse código: 


module.exports = app -> { 
if (process.env.NODE ENV !-- "test') ( 
app.db.sequelize.sync().done(() -> { 
app.listen(app.get("port"), () -> { 
console.log( NTask API - porta ${app.get("port")F ); 
33 
p; 





Para terminar o nosso setup de ambiente de testes, prepararemos algumas 
configurações específicas do Mocha, para que ele carregue o servidor da API 
eos módulos chai e supertest, como variáveis globais. O motivo disso 
é agilizar a execução dos testes, afinal, cada um carregaria esses módulos e, 
se centralizarmos tudo isso em um único arquivo, economizaríamos alguns 
milissegundos de execução dos testes. Para implementar essa boa prática, crie 
o arquivo test/helpers,js: 


import supertest from "supertest"; 
import chai from "chai"; 
import app from "../index.js"; 


global.app - app; 
global.request = supertest(app); 


global.expect - chai.expect; 


Em seguida, vamos criar um simples arquivo que permite incluir paráme- 
tros de configurações para o comando Mocha, Este será responsável por car- 
regar o test/helpers.js, e terá também uma flag -- reporter spec 
para usar report mais detalhado dos testes que são executados. Depois, va- 
mos incluir a flag -- compilers js:babel/register para que o Mocha 


utilize o módulo babel para reconhecer e executar os códigos dos testes no 





padrão JavaScript ES6. 
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Por último, será incluída a flag --slow 5000 para que a bateria de 
testes demorem 5 segundos para iniciar (tempo suficiente para o servi- 
dor de API carregar as tabelas do Sequelize corretamente). Crie o arquivo 
test/mocha.opts com oa seguintes parâmetros: 

--require test/helpers 
--reporter spec 

--compilers js;babel/register 
-.slow 5000 


Criando o primeiro teste 


Pronto! Terminamos o setup básico para execução de testes com Mocha. 
Vamos testar alguma coisa? Que tal testarmos o routes/index.js? Eleé 
muito simples de se testar: basicamente vamos testar o JSON de retorno dele, 
comparando se o resultado é igual ao JSON (status: "NTask API") 

Para criar nosso primeiro teste, realizaremos uma requisição GET /. 





Por meio da função request.get("/"), será validado se a requisição re- 
torna Status 200, Para finalizar, é feita uma comparação entre objeto 


req.body com o objeto expected para validar se ambos são iguais, via 
função expect(res.body).to.egl(expected), 





Para implementar esse teste, crie o arquivo test/routes/index.js 
com os seguintes códigos: 


describe("Routes: Index", (O) -> 1 
describe("GET /", () -» ( 
it("returns the API status", done -> { 
request .get("/") 
,expect(200) 
,end((Cerr, res) -> ( 
const expected - (status: "NTask API"); 
expect (res . body) .to.eql(expected); 
done (err); 
)); 
+; 
sas 
}); 


Para executar nosso primeiro teste, basta rodar o comando: 
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npm test 


Após a sua execução, você terá um resultado semelhante a esta figura: 


- mtosk-gn191,0.0 tes 


2 MEOE IWNetest mocio t 





Fig. 8.2: Executando o primeiro teste 


8.3 Testando endpoint de autenticação da API 


Sem enrolações! Nesta seção, vamos implementar testes e mais testes so- 
bre os endpoints da nossa aplicação. Para começar, testaremos o endpoint 
routes/token.js, que é responsável por gerar tokens para os usuários au- 
tenticados. 





Basicamente, esse endpoint terá 4 testes que vào validar: 


* Requisição autenticada por um usuário válido; 
* Requisição com e-mail válido informando senha incorreta; 
* Requisição informando um e-mail não cadastrado; 


* Requisição sem e-mail e sem senha. 


Crie o teste test/routes/token.js com a seguinte estrutura: 


describe("Routes: Token", O -> 1 
const Users - app.db models . Users; 
describe("POST /token", O -> ( 

beforeEach(done => 1 
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// Codigo de pré-teste 
HDs 
describe("status 200", O -> 1 
it("returns authenticated user token", done -> ( 
Godigo do teste,. 
); 
H; 
describe("status 401", (O) -> ( 
it("throws error when password is incorrect", done -> { 
Codigo do teste... 
)35 
it("throws error when email not exist", done -> { 
Codigo do teste... 


Hs 
it("throws error when email and password are blank", 
done => 1 
Código do teste... 
Hs 
)); 
Ds 
Hr 


Para iniciar, vamos codar a lógica interna da função beforeEach(), 
Essa função é executada antes de cada teste, e basicamente terá de 


cadastrar um usuário na base. Para isso, vamos usar o modelo 
app.db.models.Users e suas funções: Users.destroy((where: 


13%) para limpar a tabela de usuários, e Users.create para cadastrar um 
novo em seguida, a cada execução dos testes. Isso vai permitir testar utili- 
zando um usuário válido. 


beforeEach(done => { 
Users 


.destroy((iwhere: (JH) 
.then(() -> Users .create({ 


name; "John", 
email: "johnümall.net", 
password: "12345" 


)2) 


9] 
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.then(done ()); 
s 


Agora, vamos implementar teste a teste. — Comecaremos com o pri- 
meiro teste, que retorna um caso de sucesso. Vamos usar a função 
request.post('/token”) para fazer uma requisição do token, já envi- 
ando o e-mail e a senha de um usuário válido através da função sendO, A 
função expect(200) indica que a resposta esperada é por meio do status 
200 do HTTP. 

Para finalizar o teste, no callback da função end(err, res), é va- 
lidado se o objeto res.body retorna o atributo token via função 
expect(res.body).to.include.keys("token'). Para encerrar um 
teste, é obrigatória a execução do callback done() no final do teste, pois é 
ela a função que o finaliza. 

Preferencialmente, sempre envie a variável Err como parâmetro para 
essa função ( done(err)), pois, caso ocorra um erro na requisição, serão 
exibidos no terminal os detalhes do erro ocorrido. Veja a seguir o código 





completo desse teste: 


it("returns authenticated user token", done -> ( 
request .post("/token") 
. sendC1( 
email; "johnümail.net", 
password: "123485" 
+) 
, expect (200) 
end (err, res) => 1 
expect(íres.body).to. include .keys("token"); 
done (err); 
HD; 
)); 


Em seguida, vamos testar o caso do envio de senha incorreta, esperando 
que ela retorne status 401 de acesso nào autorizado. Esse teste será mais sim- 
ples, pois basicamente vamos testar apenas se a requisição retornará erro de 
status 401 através da função expect(401), 
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it("throws error when password is incorrect", done -> 1 
request .post(" /token") 
,send(1 
email: "johnümail.net", 
password: "SENHA ERRADA" 
H) 
, expect (401) 
.end((Cerr, res) -> { 
done (err); 
p; 
H); 


Também vamos implementar o teste de e-mail inexistente na tabela de 
usuários. As funções usadas nele são semelhantes ao teste anterior. 


it("throws error when email not exist", done -> { 
request .post(" /tokoen" ) 
.send(C1 
email: "EMAIL. ERRADO", 
password; "SENHA ERRADA" 
) 
,expect(401) 
,end(Cerr, res) -> ( 
done (err); 
)2; 
}); 


E, para finalizar, vamos criar os testes de status 401, quando não é enviado 
um e-mail e nem uma senha. Este é mais simples ainda, pois não serão envi- 





ados parámetros no corpo da requisição, basicamente ele é validado através 
da função expect(401) e ponto final. 


it("throws error when email and password are blank", done -> 1 
request .post("/token") 
expect (401) 
.end((err, res) -> ( 
done (err); 
)2; 
p; 
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Conclusão 


Parabéns! Se você implementou até aqui e rodou novamente o comando 
npm test, você provavelmente terá um resultado semelhante a esta figura: 





2.0 L bul 
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ELSU G 01.0.9 tes 
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Fig. 8.3: Resultado dos testes de autenticação 


Continue lendo, pois este assunto de testes é um pouco extenso, e vamos 
continuá-lo no próximo capítulo, com a parte final da implementação dos 
testes nos endpoints da API. 
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Testando a aplicação — Parte 2 


Dando continuidade à implementação dos testes para nossa API, vamos agora 
focar nos testes para os recursos: tarefas e usuários. 


9.1 Testando os endpoints das tarefas 


Para testarmos os endpoints do recurso tarefas, teremos de fazer um pequeno 
contorno para burlar a autenticação JWT na aplicação. Afinal, será necessário 
para testarmos corretamente os resultados desse recurso e também dos de- 
mais que envolvam uma autenticação de usuário. Para começar, vamos criar 
a estrutura dos testes para tarefas. 

Crie o arquivo test/routes/tasks.js com o seguinte layout: 


import jwt from "jwt-simple"; 
describe("Routes: Tasks", () -> ( 
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const Users - app.db.models.Users; 
const Tasks - app.db.models.Tasks; 
const jwtSecret - app.libs.config. jwtSecret; 
let token; 
let fakeTask; 
beforeEach(done => 1 
// Código de testes 
H); 
describe ("GET /tasks", (O) -> ( 
describe("status 200", () -> { 
it("returns a list of tasks", done -> ( 
// Código de testes 
H); 


H); 
describe ("POST /tasks/", O -> ( 
describe("status 200", O) -> { 
it("creates a new task", done -> ( 
// Côdigo de testes 
Hj; 
»; 
H; 
describe ("GET /tasks/:id", O -> { 
describe("status 200", O -> ( 
it("returns one task", done -> { 
// Dôdigo de testes 
»; 
H); 
describe("status 404", (O) -> ( 
it("throws error when task not exist", done -> ( 
// Goódigo de testes 
)3; 
p; 
)3; 
describe("PUT /tasks/:id", O -> 1 
describe("status 204", () -> ( 
it("updates a task", done -> 1 
// Código de testes 
DD: 
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H; 
)s 
describe("DELETE /tasks/:id", O -> ( 
describe("status 204", () -> ( 
it("removes a task", done -> ( 
Godigo de testes 
*); 
* 
E 


)); 


Entrando em detalhes sobre como vamos burlar a autenticação para 
realizar os testes, praticamente vamos reutilizar o módulo JWt-simple 
para criar um token válido que será usado no cabeçalho de todos os tes- 
tes. Esse token será gerado repetidamente dentro do callback da fun- 
cáo beforeEach(done), Mas, para gerá-lo, antes teremos de excluir to- 
dos os usuários por meio da função Users.destroy((where: 133) 
para, em seguida, criar um novo e único usuário na base via função 
Users.create(). 


Faremos o mesmo fluxo para criação de tarefas, porém no lugar da função 
Tasks.create, será usada a função l'asks.bulkCreate(0, que permite 
enviar um array de várias tarefas a serem inseridas em uma única execução 
(essa função é muito útil para inclusão em lote de dados). 

As tarefas utilizarão o User.id do usuário, criado para garantir que elas 
são do usuário autenticado. Na reta final, pegamos a primeira tarefa criada 
por meio do trecho fake Task = tasks[O] para reutilizar seu İd nos tes- 
tes que necessitam de um İd de tarefa como parámetro na rota. Também ge- 
ramos um token válido através da função Jwt.encode(tid: user.id), 
JwtSecret). 

Ambos os objetos fake Task e token são criados em um escopo acima 
da função beforeEach(done), para que sejam reutilizados nos testes. Para 





entender em detalhes, faça a seguinte implementação: 


beforeEach(done => 1 


Users 
.destroy([where: (JJ) 
,then(() -=> Users.create(í 
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name: "John", 
email; "johnümail.net", 


password: "12345" 


})) 
,then(user -> { 
Tasks 
.destroy((where: (JJ) 
.then(() -> Tasks .bulkCreate([{ 
id: 1, 
title: "Work", 
user_id: user, id 
fp t 


id: 2, 
title: "Study", 
user id: user.id 

H2) 

.then(tasks -> { 
fakeTask - tasks[0]; 
token - jwt.encode({id: user. id), jwtSecret); 
done () ; 

H); 

2: 
)5; 





Com as rotinas de pré-testes pronta, vamos codificar todos os testes dos 
endpoints de tarefas, começando com o teste para a rota GET /tasks, 
Nele, é realizada uma requisição via função request.get( /tasks"), 
usando também a função set("Authorization", JWT ${token}’, 
que permite enviar um cabeçalho na requisição, que neste caso, é enviado o 
cabeçalho Authorization com o valor do token de autenticação. 





Para garantir que o teste seja realizado com sucesso: 


1) Checamos o status 200 via função expect(200): 
2) Aplicamos uma simples validação para garantir que 


será retornado um array de tamanho 2 via função 
expect(res.body).to.have.length(2); 
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3) Comparamos se os títulos das 2 tarefas são iguais as que foram criadas pela 
função Tasks.bulkCreateQ, 


describe("GET /tasks", (O -> 1 
describe("status 200", () -> ( 
it("returns a list of tasks", done -> { 
request .get (" /t asks") 

.set("Authorization", 'JWT $(token)') 

expect (200) 

,end(Cerr, res) -> ( 
expect(res.body).to.have.length(2); 
expect(res.body[0].title).to.eql("Work'"); 
expect(res.body[1].title).to.eql("Study"); 
done (err); 

H; 


Para testar o caso de sucesso da rota POST /tasks, nào há segredos: 
basicamente informamos o cabeçalho com token de autenticação e um título 
para uma nova tarefa. Como saída, testamos se a resposta retorna Status 
200. e se o objeto req.body possui o mesmo título que foi enviado para 
cadastrar essa nova tarefa. 


describe("PUST /tasks", (O) -> ( 
describe("status 200", O -> ( 
it("creates a new task", done -> ( 
request .post(" /tasks") 

.Set("Authorization", 'JWT $(token)") 

.send((title: "Run")) 

expect (200) 

.end((err, res) -> ( 
expect(res.body.title).to.eql("Run"); 
expect(res.body.done).to.be.false; 
done(err); 

)); 

H); 
H; 
j yd 
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Agora vamos testar 2 simples fluxos da rota GET /tasks/:id, No caso 
de sucesso, usaremos o id do objeto fakeTask para garantir que retorne 
uma tarefa válida. Para testar o comportamento quando é informado um 
Id de tarefa inválido, vamos utilizar a função expect(404) para testar o 
status 404, que indica que a requisição não encontrou um recurso. 


describe("GET /tasks/:id", O) -> ( 
describe ("status 200", () -> ( 
it("returns one task", done => { 
request.get('/tasks/$(fakeTask.id)') 

.set("Authorization", 'JWT $Íítoken)') 

,expect(200) 

.end((err, res) -> { 
expect(res.body.title).to.egl("Work"); 
done (err); 

)5; 

p; 
; 
describe("status 404", O -> ( 
it("throws error when task not exist", done -> ( 
request .get (" /tasks/0" ) 

.Sset("Authorization", 'JWT $Í(token)') 

,expect(404) 

,end((err, res) -> done(err)); 

+); 
); 
33; 


Para finalizar os testes, vamos testar apenas o comportamento de su- 
cesso das rotas PUT /tasks/:id e DELETE /tasks/:id. Ambos usa- 
rão praticamente as mesmas funções, exceto que um teste executará a função 
request.put() eo outro, request.delete(), Porém, ambos vão espe- 
rar que o sucesso da requisição retorne um status 204 através da função 
expect(204). 


describe("PUT /tasks/:id", O -> 1 
describe ("status 204", (O) -> 1 
it ("updates a task", done -> ( 
request.put(' /tasks/$(fakeTask, id}`) 
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.set("Authorization", 'JWT $Í(token)') 
.send(( 

title: "Travel", 

done: true 


H} 
expect (204) 
.end((err, res) -> done(err)); 
)2; 
Hs 


D; 
describe("DELETE /tasks/:id", O -> 1 
describe("status 204", () -> ( 
it("removes a task", done -> { 
request .delete('/tasks/$(fakeTask. id)") 

.set("Authorization", 'JWT $Í(token])') 
,expect(204) 
.end((err, res) -> done(err)); 


Parabéns! Acabamos os testes do recurso tarefas. Caso vocé execute no- 
vamente o comando "pm test, você terá o seguinte resultado: 


101 


9.2. Testando os endpoints de usuário Casa do Código 


a > s nest 


Routes: Tasks 
GET /tasks 


st "pw tv ut 


Routes Token 


POST /tokem 





Fig. 9.1: Testando endpoints de tarefas 


9.2 Testando os endpoints de usuário 


Para testar o recurso de gestão de usuários, é mais simples ainda, pois prati- 
camente vamos utilizar tudo o que já foi explicado nos testes anteriores. Para 
começar, crie o arquivo test/routes/users.JS coma seguinte estrutura: 


import jwt from "jwt-simple"; 
describe("Routes: Tasks", (D) -> 1 

const Users - app.db.models.Users; 

const jwtSecret - app.libs.config. jwtSecret; 


let token; 
beforeEach(done => 1 
Codigo de teste 
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)5; 
describe("GET /user", () -> ( 
describe("status 200", O -> 1 
it("returns an authenticated user", done -> ( 


// Código de teste 


describe("DELETE /user", O -> 1 
describe("status 200", () -> ( 
it("deletes an authenticated user", done => { 
// Código de teste 


HD; 
*)s 
describe("PDST /users", O -> 1 
describe("status 200", O -> ( 
it("creates a new user", done -> ( 
// Código de teste 


A lógica de pré-testes será mais simplificada, porém terá também a gera- 
ção de um token de autenticação válido. Veja a seguir como implementar a 
funcáo beforeEach(done): 


beforeEach(done -> 1 
Users 
.destroy((where: ())) 
,then(() -> Users .create(( 
name: "John", 
email: "johnOmail.net", 
password: "12345" 
)2) 
,then(user -=> ( 
token - jwt.encode((id: user.id), jwtSecret); 
done (); 
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P: 
Ms 


Agora, para implementar os testes, vamos começar testando a requisição 
GET /user, que retorna os dados de um usuário autenticado, que basica- 
mente envia um token de autenticação e recebe como resposta os dados do 
usuário que foi criado na função beforeEach(done), 


describe("GET /user", O -> ( 
describe ("status 200", () -> { 
it ("returns an authenticated user", done => { 
request .get ("/user" ) 

set("Authorization", `JWT ${token}") 

expect (200) 

.end((err, res) -> 1 
expect(res.body.name).to.eqgl("John"); 
expect(res.body.email).to.eqgl("johnümail.net"); 
done (err); 

P 

p; 
H); 
}3; 


Em seguida, codificaremos os testes para a rota DELETE /user, para 
testar se a exclusão de usuário autenticado. Os testes para esse caso são mais 





simples: enviar um token e esperar como sucesso o status 204, 


describe ("DELETE /user", O -> { 
describe ("status 200", O) -> 1 
it("deletes an authenticated user", done -> { 
request .delete("/user") 
,set("Authorization", 'JWT $í(token]') 
,expect(204) 
.end((err, res) -> done(err)); 
HD; 
HP; 
33; 


Para finalizar, vamos implementar o teste mais simples que faz um cadas- 
tro de novo usuário na API. Este não exige token, afinal, é uma rota aberta 
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para novos usuários cadastrarem uma conta na aplicação. Veja a seguir o có- 
digo desse teste: 


describe("PDST /users", (O) -> 1 
describe("status 200", () -> ( 
it("creates a new user", done -> { 
request .post("/users") 

.send(C1 
name; "Mary", 
email: "maryümail.net", 
password: "12345" 

H) 

, expect (200) 

.end((err, res) -> { 
expect(res.body.name).to.eql("Mary"); 
expect(res.body.email).to.eql("mary8mail.net"); 
done(err); 


i $ f- 


Para testar, execute o comando npm test, Se tudo rodar com sucesso, 
você terá um lindo report semelhante a este: 
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Routez: Index 
GET / 


Routes: Tasks 
GET /tosks 
status 200 


POST [tasks 
status 209 


GET A ilc ELT. 
Şi guus DUO 


status 484 


PUT /tasks/:1d 
status 204 


DELETE /toses/cte 
status 204 


Routes: Token 
POST /token 
status 200 


stotus 48) 


Routes Tasks 
GET /user 
status 299 


DELETE /user 





Fig. 9.2: Testando endpoints de usuário 


Conclusão 


Se você chegou até esta etapa, então você já desenvolveu uma pequena, 
porém poderosa, API, utilizando Node.js e banco de dados do tipo SQL. Tudo 
isso já funcionando com o mínimo de testes para garantir a qualidade de có- 
digo no projeto. 
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No próximo capítulo, vamos usar uma ferramenta muito útil para geração 
de documentação de APIs. Continue a leitura que ainda tem muita coisa legal 
para explorarmos! 
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Documentando uma API 


Se você chegou até este capítulo e sua aplicação está funcionando correta- 





mente — com rotas para os recursos de gestão de tarefas e usuários, integra- 
dos ao banco de dados, e com autenticação de usuários através do JSON Web 
Token —, meus parabéns! Vocé criou, seguindo boas práticas, uma API Rest 





utilizando Node.js. Se vocé pretende usar esse projeto piloto como base para 
construir sua própria API, então você já tem uma aplicação pronta para enviá- 
la para um servidor de ambiente de produção. 


10.1 Introdução a ferramenta apiDoc 


Neste capítulo, aprenderemos como documentar os endpoints de uma API, 
afinal, é uma boa prática disponibilizar uma documentação sobre como as 
aplicações clientes poderão se autenticar e consumir os dados de uma API 
O mais legal é que vamos utilizar uma ferramenta muito simples de usar, e 
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toda a documentação da nossa aplicação será feita por meio de comentários 
padronizados dentro dos códigos das rotas. 

Usaremos a ferramenta apiDoc, um módulo Node.js que, através da lei- 
tura de seus comentários padronizados, ele consegue gerar uma documenta- 
ção bonita e elegante para APIs. 





APIDOC 
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Fig. 10.1: Homepage do apiDoc 


Esse módulo é um CLI (Command Line Interface), e & recomendável 


instalá-lo como módulo global (através do comando npm install -g), 
Porém, no nosso caso, vamos criar um comando "PI"! para usá-lo toda vez 
que iniciarmos o servidor da API. Logo, sua instalação será como um mó- 
dulo local, semelhante aos demais que já foram instalados. 


Instale-o pelo comando: 


npn install apidoc --save-dev 


Como o objeto atualiza a documentação toda vez que iniciarmos o 
servidor, então vamos modificar o comando npm start, Primeiro, va- 
mos criar o novo comando pm run apidoc, que executará o comando 
apidoc -i routes/ -o public/apidoc, Depois, modificaremos o 


atributo Scripts.start para que ele gere a documentação da API e, 
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em seguida, inicie o servidor da aplicação. Também incluiremos o atributo 
apidoc.name, que será o título da página de documentação da APL 
Abra e edite o package.json, fazendo a seguinte alteração: 


{ 

"name"; "ntask-api", 

"version": "1.0.0", 

"description"; "API de gestão de tarefas", 

"main": "index. js”, 

"scripts": { 
"start": "npm run apidoc k& babel-node index. js", 
"test": "NODE ENV-test mocha test/**/x, js" 
"apidoc"; "apidoc -i routes/ -o public/apidoc" 

k, 

"author": "Caio Ribeiro Pereira”, 

"apidoc": ( 
"name": "Documentação - Node Task API" 

}, 


"dependencies"; { 

"babel": "75.8.23", 
"berypt"; "70.5.5", 
"body-parser": "^1.13.3", 
"consign": "^0.1.2", 
"express"; "^4,13,.3", 
"jwt-simple": "^0.3.1", 
"passport"; "0.3.0", 
"passport-jwt": "71.2.1", 
"sequelize": "^3.9.0", 
"sglite3": "^3,1.0" 

k, 

"devDependencies": ( 
"spidoc"; "^0.13.1", 
"chai"; "^3.3.0", 
"mocha"; "12.3.3", 


"supertest"; "^1.1,0" 


A partir de agora, toda vez que você executar o comando pm start, 
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se você quiser apenas gerar uma nova documentação sem iniciar o servidor, 
você pode rodar apenas nem run apidoc, Ambos os comandos vào varrer 
e procurar todos os comentários existentes no diretório routes para gerar 
a documentação da API, que será salva na pasta public/apidoc e, em se- 
guida, iniciará o servidor. 

Para que seja possível visualizar a página de documentação, primeiro te- 
remos de habilitar o servidor de arquivos estáticos do Express, para que ele 
sirva todo o conteúdo estático existente na pasta public, Para habilitá-lo, 
basta incluir o middleware app.use(express.static("public")) no 
final do arquivo libs/middlewares.js, Veja como fica: 


import bodyParser from "body-parser"; 
import express from "express"; 
module.exports - app -> ( 
app.set("port", 3000); 
app.set("json spaces", 4); 
app. use(bodyParser. json()); 
app. use (app. auth initialize()); 


app.use((req, res, next) -> { 
delete req.body.id; 
next (); 
H; 
app.use(express.static("public")); 


Ks 


Para validar se está tudo funcionando, vamos documentar, por enquanto, 
o endpoint de status da API — o endpoint / —, e vamos usar os seguintes 
comentários: 





e (Capi: informa o tipo, endereço e título do endpoint; 
e (MapiGroup: informa o nome do grupo de endpoints; 


e MapiSuccess: descreve os campos e seus tipos de dados em uma res- 
posta de sucesso; 


e MapiSuccessExample: apresenta um exemplo de resposta de su- 
cesso. 
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Para documentar esse endpoint, edite o arquivo routes/index.js 


com o seguinte código: 


module . exports - app -> { 


/»» 


* Qapi 


API Status 


* OapiGroup Status 


* Oapisuccess 


* QapisS 


k 


* j 


(String) status Mensagem de status da API 


nccessExample {json} Sucesso 
1 200 UK 
("status": "NTaásk APT") 


app.get("/", (req, res) -> 1 
res. json((status; "NTask API")); 


j Y $- 
f; 


Para testar essas alterações, basta reiniciar seu servidor por meio do co- 
mando npm start e, em seguida, acessar no browser o endereço: http: 


//localhost:3000/apidoc. 
Se nào ocorrer erros, você visualizará uma linda página de documentação 


de APIs. 


Documentação - Node Task AP! au 


AF! de gestão de tatefas 


Status 
Status - API Status TT 
T 
urcrw 229 

MI Free Ceres to 





Fig. 10.2: Documentação de Status da API 
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102 Documentando a geração de tokens 


Agora, vamos explorar mais a fundo as funcionalidades do apiDoc, documen- 
tando as restantes rotas da API. 

Para iniciar, vamos documentar a rota /token, Ela possui alguns deta- 
lhes extras para ser documentados. Nela, não só usaremos os itens explicados 
na seção anterior como também utilizaremos esses novos itens: 


e (QapiParam: descreve um parámetro de entrada, que pode ser ou não 
obrigatório o seu envio em uma requisição; 


e MapiParamExample: apresenta um exemplo real de parámetros de 
entrada, no nosso caso, vamos exibir um JSON de entrada; 


e MapiErrorExample: mostra um exemplo de erro que a API pode ge- 
rar se nào forem enviado os parámetros corretamente. 


Para entender na prática o uso desses novos itens, edite o 
routes/token.Js, seguindo os comentários a seguir: 


import jwt from "jwt-simple"; 
module.exports - app -> { 
const cfg - app.libs. config; 
const Users - app.db.models.Users; 
EE, 
* Qapi {post} /token Token autenticado 


* ĝapiGroup Credencial 
4 a 


* QapiParam {String} email Email de usuári 

* QapiParam {String} password Senha de usuário 
* QapiParamExample {json} Entrada 

` [ 

+ "email": "johnüconnor.net", 

+ “password "123456' 

* | 

* QOapiSuccess (String) token Token de usuário autenticado 
* QapiSuccessExample ijsonj ICEE 

+ HTTP/1.1 200 OK 

+ (rT n": "xyz.abc.123.hgf"] 

* QapiErrorExample {json} Erro de autenticaçã: 
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+ HTTP/1.1 401 Unauthorized 
+ 
app.post("/token", (req, res) -> { 
Logica do /token que foi explicada no capitulo 


)) 


"T 


103 Documentando recurso de gestão de usuá- 
rios 
Nesta e na próxima seção, vamos documentar os 2 recursos principais da API: 


usuários e tarefas. Como a maioria das rotas desses recursos necessita de um 
Token de usuário autenticado — que é enviado pelo header da requisição —, 





vamos usar os seguintes itens para descrever seus parâmetros: 


e WapiHeader: descreve nome e tipo de dado de um header; 


e MapiHeaderExample: exibe um exemplo de header a ser usado na 
requisição. 


Abrao routes/users.)s e vamos começar documentando a rota GET 
/user, 


module .exports = app -> f 

const Users - app.db, models Users; 

app.route("/user") 
.all(app.auth.authenticate()) 
EE, 
* Qapi {get} /user Exibe usuario autenticado 
* QapiGroup Usuārio 
* QapiHeader (String) Authorization Token de usuário 
* ÜOapiHeaderExample {json} Header 
M ["Authorization": "JWT xyz.abc.123.hgf"] 


* QapiSuccess {Number} id Id de registro 


* QapiSuccess {String} name Nome 

* OapiSuccess {String} email Email 
* OapiSuccessExample {json} Sucesso 
+ HTTP/1,1 200 OK 
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^ i 

* "id"; E, 

* "name": "John Connor", 

* "email": "johnQOconnor.net" 


* ) 
* QapiErrorExample {json} Erro de consulta 
+ HTTP/1,1 412 Precondition Failed 
ij 
.get((req, res) -> ( 
// Lógica explicada no capitulo 7 
p» 
// continuação das rotas DELETE e POST 


Em seguida, vamos documentar a rota DELETE /user: 
/ »* 
Qapi {delete} /user Exclui usuario autenticado 
0apiGroup Usuário 
QapiHeader (String) Authorization Token de usuário 
OapiHeaderExample {json} Header 
["Authorization": "JWT xyz.abc.123.hgf") 
QGapiSuccessExample {json} Sucesso 
HTTP/1.1 204 No Content 
OapiErrorExample {json} Erro na exclusão 
HTTP/1.1 412 Precondition Failed 


AX 0 X* E + EEE + + 


/ 

.delete(C(req, res) -> { 

// Lógica explicada no capitulo 7 
)) 


// continuação da rota POST 


Para finalizar, ainda no mesmo arquivo routes/users.js, documen- 
taremos sua última rota, a POST /user, usando vários itens para descrever 
todos os seus campos de entrada e saída: 

f» 

Qapi (post) /users Cadastra novo usuário 
dapiGroup Usuário 

dapiParam (String) name Nome 


+ + + + 


QapiParam (String) email Email 
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t 


OapiParam {String} password Senha 
ÜapiParamExample {json} Entrada 
{ 


"name": "Jobn Connor", 


+ * + 


* 


"email": "johnOconnor,net", 
"password": "123456" 
} 


dapisucci 


* 


* 


n 
tu 
Dà 
"m 


(Number) id Id de registro 
üapiSuccess (String) name Nome 
QGapiSuccess (String) email Email 


ÜapiSuccess (Date) created at Data de cadastro 
ÜapiSuccessExample {json} Sucesso 

HTTP/1,1 200 OK 

Í 


+ + EEE + 


+ + 


“name”: "Iohn Connor", 


* —* 


"email": "johnüconnor.net", 
"password": "$2a$10$SK1R1", 
"updated at": "2015-09-24T15:46:;51,7782Z", 
"created at": "2015-09-24T15:46:51.7782Z" 
} 
QapiErrorExample {json} Erro no cadastro 
HTTP/1.1 412 Precondition Failed 


+” 


T + + + E S 


app.post("/users", (req, res) -> ( 
// Logica explicada no capitulo 


— 
f 


GapiSuccess (String) password Senha criptografada 
GapiSuccess (Date) updated at Data de atualização 


104 Documentando recurso de gestão de tare- 


fas 


Dando continuidade à nossa documentagào de API, vamos agora finalizar 
essa tarefa documentando os endpoints do arquivo routes/tasks,js, e 


descrevendo inicialmente a rota GET /tasks: 
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module.exports - app -> { 
const Tasks ~ app.db.models.Tasks; 
app.route("/tasks") 
.all(app.auth.authenticate()) 
f» 
Qapi (get) /tasks Lista tarefas 
dapiGroup Tarefas 
QapiHeader {String} Authorization Token de usuário 
dapiHeaderExample {json} Header 
{" Authorization": "JWT xyz.abc.123.hgf"] 
@apiSuccess {0bject[]} tasks Lista de tarefas 
QapiSuccess (Number) tasks.id Id de registro 
OapiSuccess (String) tasks.title Titulo da tarefa 
OapiSuccese (Boolean) tasks. done Tarefa foi concluida? 
OapisSuccess (Date) tasks updated at Data de atualização 
QapiSuccess {Date} tasks.created at Data de cadastro 
dapisuccess {Number} tasks user id Id do usuário 
QapiSuccessExample {json} Sucesso 
HTTP/1.1 200 OK 


[1 
"ig": E. 
"title": "Estudar", 
"done": false 


"updated at": "2015-09-24T15;46;51,7782Z", 
"created at": "2015-09-24T15:46:51.778Z", 
"user id": 1 
H 
OapiErrorExample {json} Erro de consulta 
HTTP/1,1 412 Precondition Failed 


+ + EE 5E E 5E E E EEE EEE Æ Æ E 


*/ 

.get((req, res) -> { 

// Lógica implementada no capitulo 7 
I» 


Em seguida, documentaremos a rota POST /tasks: 


/»* 

* Gapi (post) /tasks Cadastra uma tarefas 

* OapiGroup Tarefas 

* QapiHeader {String} Authorization Token de usuário 
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dapiHeaderExample {json} Header 
["Authorization": "JWT xyz.abc.123.hgf"] 
QapiParam (String) title Título da tarefa 
OapiParamExample {json} Entrada 
["title": "Estudar"]) 
QapiSuccess (Number) id Id de registro 
OapiSuccess {String} title Titulo da tarefa 
QapiSuccess {Boolean} done-false Tarefa foi concluidaT 
OapiSuccess {Date} updated at Data de atualização 
QapiSuccess (Date) created at Data de cadastro 
QapiSuccess (Number) user id Id do usuário 
QapiSuccessExample {json} Sucesso 
HTTP/1.1 200 0K 
{ 
"id": f, 
"title": "Estudar", 
"done": false, 
"updated at"; "2015-09-24T15:46:51,.7782Z", 
"created at": "2015-09-24T15:46:51.7782Z", 
"user id": 1 
) 
OapiErrorExample {json} Erro de consulta 
HTTP/1.1 412 Precondition Failed 


+ 0 E EE XE åE E EE ŻE EEE EEE * 


»/ 

post((req, res) -> ( 

// Lógica implementada no capítulo 7 
p 


Depois, vamos documentar a rota GET /tasks/:id, com os seguintes 
comentários: 


/»» 
Oapi (get) /tasks/:id Exibs uma tarefa 
OapiGroup Tarefas 
0apiHeader (String) Authorization Token de usuário 
QapiHeaderExample {json} Header 
Í"Authorization": "JWT xyz.abc.123.hgf") 
QapiParam (id) id Id da tarefa 
QapiSuccess (Number) id Id de registro 


+ 0 * + E + E X 
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* OapiSuccess (String) title Titulo da tarefa 

* ÜapiSuccess {Boolean} done Tarefa foi concluída? 
* QapiSuccess (Date) updated at Data de atualização 
* QapiSuccess (Date) created at Data de cadastro 

* QapiSuccess (Number) user id Id do usuário 

* QapiSuccessExample {json} Sucesso 

* HTTP/1.1 200 0K 

* t 

* "id"; 1, 

* "title": "Estudar", 

* "done": false 

* "updated at": "2015-09-224T15:46:51,7782Z", 

* "created at"; "20156-09.24T15:46,51,7782", 

* "user id": 1 

* } 

* QapiErrorExample {json} Tarefa nào existe 

* HTTP/1.1 404 Not Found 

* GapiErrorExample {json} Erro de consulta 

* HTIP/1.1 412 Precondition Failed 

x/ 


get((req, res) -> 1 
// Logica implementada no capitulo 7 
p 


Agora, a PUT /tasks/:id: 


(em 
* Gapi {put} /tasks/:id Atualiza uma tarefa 
* QapiGroup Tarefas 
* QapiHeader (String) Authorization Token de usuário 
* üapiHeaderExample {json} Header 
* ("Authorization", "JWT xyz.abc.123.hgf") 
* OapiParam fid) id Id da tarefa 
* OapiParam (String) title Titulo da tarefa 
* QapiParam {Boolean} done Tarefa foi concluida? 
* QapiParamExample {json} Entrada 
* 1 
* "title": "Trabalhar", 
* "done"; true 
* } 
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* OapiSuccessExample {json} Sucesso 
* HITP/1.1 204 No Content 
* QapiErrorExample {json} Erro de consulta 
* HTTP/1.1 412 Precondition Failed 
T 
.put((req, res) -> { 
/ Logica implementada no capitulo 7 


H) 


Por último, vamos finalizar este capítulo documentando a rota DELETE 
/tasks/:id: 


[40% 
* Oapi (delete) /tasks/:id Exclui uma tarefa 
* QapiGroup Tarefas 
* OapiHeader (String) Authorization Token de usuário 
* QapiHeaderExample {json} Header 
* ["Authorization": "JWT xyz.abc.123.hgf") 
* QapiParam {id} id Id da tarefa 
* OapiSuccessExample {json} Sucesso 
* HTTF/1.1 204 No Content 
* OapiErrorExample {json} Erro de consulta 
* HTTP/1.1 412 Precondition Failed 
ij 
.delete((req, res) -> ( 
/ Logica implementada no capitulo 7 
HD; 
k; 


Vamos testar? Basta reiniciar o servidor e depois acesse o endereço: http: 
/Nocalhost:3000/apidoc. 


Dessa vez, temos uma página de documentação completa que descreve 
bem o passo a passo para um novo desenvolvedor criar uma aplicação cliente, 
para consumir nossa API. 
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Z Es 


ET | Documentação - Node Task API ute 


^F! de gestão de tarefas 





Credencial 


Crodenctal - Token autenticado 103 


Agora à 
documentação 
esta completa! 





Fig. 10.3: Agora, a documentação da API está completa! 


105 Conclusão 





Parabéns! Acabamos mais um excelente capítulo. Agora não só temos uma 
API funcional como também uma documentação completa para permitir que 
outros desenvolvedores criem aplicações client-side utilizando nossa API. 
Continue lendo, pois, no próximo episódio, vamos incluir alguns fra- 
meworks e boas práticas para que nossa API trabalhe em ambiente de pro- 


dução corretamente. 
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Preparando o ambiente de 
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11.1 Introdução ao CORS 


Caso você não saiba, o CORS (Cross-origin resource sharing) é um mecanismo 
muito importante do HTTP. Ele é responsável por permitir ou barrar requi- 
sições assíncronas que são realizadas por outros domínios. 

O CORS, na prática, são apenas headers do HTTP que são incluídos no 
server-side da aplicação. Tais headers podem informar qual domínio poderá 
consumir a API, quais métodos do HTTP serão permitidos e, principalmente, 
quais endpoints serão compartilhados de forma pública para outros domínios 
de outras aplicações consumirem. 
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11.2 Habilitando CORS na API 


Como estamos desenvolvendo uma API que servirá dados para qualquer tipo 
de aplicação cliente, então teremos de habilitar o CORS como middleware 
global, para que todos endpoints sejam püblicos. Ou seja, para que qualquer 
cliente possa realizar requisições em nossa API. Para habilitar o CORS na API 
vamos instalar e usar o módulo COFS: 


npn install cors --save 


Em seguida, vamos iniciá-lo via função app.use(cors() no arquivo 
de middlewares, o libs/middlewares js: 


import bodyParser from "body-parser"; 
import express from "express"; 
import cors from "cors"; 


module.exports - app -> f 
app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(cors()); 
app.use(bodyParser.json(); 
app.use(app.auth.initialize O); 
app.use((req, res, next) -> 1 

delete req.body.id; 

next (); 
p; 
app.use(express.static("public")); 


Is 


Ao usar somente a função COrs(), estaremos liberando acesso completo 
de nossa API para qualquer cliente consumir. Porém, o recomendado é ter 
controle de quais domínios clientes vào acessá-la, quais métodos vào utilizar 
e, principalmente, quais headers serão obrigatórios para o cliente informar 
no momento da requisição. No nosso caso, vamos configurar apenas trés atri- 
butos: Origin (domínios permitidos), methods (métodos permitidos) e 
allowedHeaders (headers obrigatórios). 

Ainda no libs/middlewares.js, modifique a função 
app.use(cors()) por esta: 
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import bodyParser from "body-parser"; 
import express from "express"; 
import cors from "cors"; 


module.exports - app -> { 
app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(cors(( 
origin: ["http://localhost:3001"], 
methods: ["GET", "POST", "PUT", "DELETE"], 
allowedHeaders: ["Content-Type", "Authorization"] 
Do); 
app . use (bodyParser. json()); 
app . use (app. auth .initialize()); 
app.use((req, res, next) -> { 
delete req.body.id; 
next(); 
H3 
app.use(express.static("public")); 


Agora temos uma API que vai aceitar somente aplicações clientes do do- 
mínio origem: http://localhost:3001. 

Fique tranquilo, pois esse domínio será a nossa aplicação cliente que va- 
mos construir em detalhes no próximo capítulo! 


Um pouco mais sobre CORS 


Para vocé estudar mais a fundo sobre o CORS, para entender seus hea- 


ders e. principalmente, como criar uma regra mais customizada para sua 
API, recomendo que acesse https://developer.mozilla.org/en-US/docs/ 
Web/HTTP/Access control CORS. 





113 Gerando logs de requisições 


Nesta seção, vamos configurar nossa aplicação para que ela reporte e gere 
arquivo de logs das requisições realizadas. Para isso, usaremos o módulo 
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Winston, que é especializado em tratar diversos tipos de logs. 

No nosso caso, os logs de requisições serão tratados por meio do módulo 
morgan, que é um middleware responsável por gerar logs das requisições no 
servidor. Também vamos tratar os logs de comandos SQLs gerados no banco 
de dados. Primeiro, instale os módulos Winston e morgan: 


npm install winston morgan --save 


Feito isso, vamos implementar um código para configurar e carregar o 
winston, Nele, verificaremos se existe a pasta 1095S, usando o módulo na- 
tivo fs (File System). Em seguida, será implementada uma simples con- 
dicional via função fs.existsSync("logs"), para checar se existe ou 


não a pasta lO9S. Se essa pasta não existir, ela será criada pela função 
fs.mkdirSync("logs"). 


Depois dessa verificação da existência da pasta logs, basta instan- 
ciar e exportar o objeto module.exports = new winston.Logger, 


Como vamos gerar arquivos de logs, o nosso objeto de logs usará como 
transports o objeto new winston.transports.File, que é respon- 


sável por criar e manter vários arquivos de logs recentes. Crie o arquivo 
libs/logger.js, da seguinte maneira: 


import fs from "fs"; 
import winston from "winston"; 


if (!fs.existsSync("logs")) { 
fs.mkdirSync("logs"); 


module .exports = new winston.Logger(1 
transports: [ 
new winston. transports.File({ 
level: "info", 
filename: "logs/app.log", 
maxsize: 1048576, 
maxFiles: 10, 
colorize: false 


}) 
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] 
Hs 


Agora, vamos utilizar nosso libs/logger.;js em dois pontos impor- 
tantes de nossa aplicação. Primeiro, usaremos para gerar logs dos coman- 
dos SQLs. Vamos modificar o arquivo libs/config.development.js 
para ele carregar nosso módulo logger, Vamos usar sua função 
logger.info() como callback do atributo logging do Sequelize para 
capturarmos cada comando SQL gerado na aplicação. Para fazer 1sso, edite 
o libs/config.development.js da seguinte maneira: 


import logger from "./logger. js"; 


module .exports - f 
database; "ntask'", 


username; "", 
password: "", 
params: { 


dialect: "sqlite", 
storage; "ntask.sqlite", 
logging: (sql) -> 1 
logger . info(' [$(new Date())] $(sq1)^); 


), 
define: { 
underscored: true 
) 
E, 


jwtSecret: "Nta$K-AP1", 


jwtSession: (session; false] 


Para finalizar, vamos utilizar o módulo logger que criamos para 
gerar logs das requisições feitas em nosso servidor. ^ Para isso, usare- 
mos o módulo morgan e incluiremos no topo dos middlewares a função 
app.use(morgan( common )) para permitir a geração de logs das requi- 
SIÇÕES. 

Para enviarmos esses logs para o nosso módulo !099er, basta adicionar 
o atributo Stream com uma função callback chamada write(message) 
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e, em seguida, enviar a variável message para nossa função de log, a 
logger.info(message), Para entender melhor essa implementação, edite 
o arquivo libs/middlewares.js da seguinte maneira: 





import bodyParser from "body-parser"; 
import express from "express"; 

import morgan from "morgan"; 

import cors from "cors"; 

import logger from "./logger.js"; 


module.exports = app -> { 

app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(morgan("common", 1 

stream: { 

write; (message) -> ( 
logger .info(message); 
) 

) 
)33; 
app . use (cors ({ 

origin; ["ħttp:;//localhħhost;3001"], 

methods: ["GET", “POST”, "PUT", "DELETE"], 

allowedHeaders: ["Content-Type", "Authorization"] 
Ho); 
app. use(bodyParser. json()); 
app.use(app.auth.initialize O); 
app.use((req, res, next) -> { 

delete req.body.id; 

next O ; 
32; 
app.use(express.static("public")); 


Para testar a geração de logs, basta reiniciar o servidor e acessar várias 
vezes qualquer endereco da API, por exemplo o http://localhost:3000/. 





Após realizar algumas requisições na API, acesse o diretório 109S da raiz 
do projeto. Lá com certeza terá um arquivo de logs com dados de requisições 
semelhantes a este: 
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Fig. 11.1: Logs das requisições 


114 Configurando processamento paralelo 
com módulo cluster 


Infelizmente, o Node.js não trabalha com threads, Isso é algo que, na opinião 
de alguns desenvolvedores, é considerado um ponto negativo, e que provoca 
um certo desinteresse em aprender ou levar a sério essa tecnologia. Entre- 
tanto, apesar de ele ser single-thread, é possível, sim, prepará-lo para traba- 
lhar com processamento paralelo. Para 1sso, existe nativamente um módulo 
chamado cluster, 

Ele basicamente instancia novos processos de uma aplicação, trabalhando 
de forma distribuída e, quando trabalhamos com uma aplicação web, esse 
módulo se encarrega de compartilhar a mesma porta da rede entre os clusters 





ativos. O número de processos a serem criados é você quem determina, e é 
claro que a boa prática é instanciar um total de processos relativo à quantidade 
de núcleos do processador do servidor, ou também uma quantidade relativa 
a núcleos X processadores. 

Por exemplo, se tenho um único processador de oito núcleos, então, posso 
instanciar oito processos, criando assim uma rede de oito clusters, Mas, caso 
tenha quatro processadores de oito núcleos cada, é possível criar uma rede de 
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trinta e dois clusters em acáo. 


Para garantir que os Clusters trabalhem de forma distribuída e organizada, 
é necessário que exista um processo pai, mais conhecido como cluster master. 
Ele é o responsável por balancear a carga de processamento entre os demais 
clusters, distribuindo-a para os processos filhos, que sáo chamados de cluster 
slave, Implementar essa técnica no Node.js é muito simples, visto que toda a 
distribuição de processamento é executada de forma abstraída para o desen- 
volvedor. 








Outra vantagem é que os Clusters s&o independentes uns dos outros. Ou 
seja, caso um Cluster saia do ar, os demais continuarão servindo a aplicação 





mantendo o sistema no ar. Porém, é necessário gerenciar as instâncias e en- 
cerramento desses clusters manualmente para garantir o retorno do cluster 
que saiu do ar. 

Com base nesses conceitos, vamos aplicar na prática a implementação de 
clusters, Crie no diretório raiz o arquivo clusters.Js, para que, por meio 
dele, seja carregado clusters da nossa aplicação. Veja o código a seguir: 


import cluster from "cluster"; 
import os from "os"; 


const CPUS - os.cpusQO; 
if (cluster.isMaster) { 
CPUS.forEach(() -> cluster.forkO); 
cluster.on("listening", worker -> ( 
console.log("Cluster kd conectado", worker .process. pid); 
); 
cluster.on("disconnect", worker -> 1 
console, log("Cluster 4d desconectado", worker .process.pid); 
+; 
cluster. on("exit'!, worker -> ( 
console. log("Cluster 4d saiu do ar", worker.process.pid); 
cluster .fork(); 


// Inicia novo cluster quando um cluster sai do ar 
H); 
} else { 
require(", /index, js"); 
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Dessa vez, para levantar o servidor, primeiro edite o package.json 
dentro do atributo SCr!DtS, para criar o comando Nem run clusters, 


conforme o código a seguir: 


"scripts": 1 


"start": "npm run apidoc && babel-node index. js", 
"clusters"; "babel-node clusters. js", 

"test": "NODE ENV-test mocha test/**/x*.js", 
"apidoc"; "apidoc -i routes/ -o public/apidoc" 


Agora, execute o comando npm run clusters, Dessa vez, a aplicação 
vai rodar de forma distribuída e, para comprovar que deu certo, você verá no 
terminal a mensagem "NTask API - porta 3000" 


o o c 


[coio ntask-opi] hoster) § npn cum clusters 


» ntosk-upit1.9.0 clusters /Uzers/calo/Documents/workspace/node 1 e/ntosk-apt 


> bobel-node cluster a 


NTusk API - porta 309€ 
NTask API - porta 3000 
Cluster 39775 conectodo 
Cluster 30/74 conectado 
NTask APT porta 3020 
Tosk API - porta 3009 
Cluster 30776 conectado 


Ciustar 30727 tnnectndo 





Fig. 112: Rodando Node.js em clusters 


Basicamente, carregamos o módulo cluster e, primeiro, verificamos 
se ele é o Cluster master via função clusterisMaster, Caso ele seja, 
rodamos um loop cujas iterações são baseadas no total de núcleos de pro- 
cessamento (CPUS) que ocorrem por meio do trecho CPUS.forEach(), 
que retorna o total de núcleos do servidor. Em cada iteração, rodamos o 
cluster.forkO que, na prática, instancia um processo filho cluster slave, 


Quando nasce um novo processo (neste caso, um processo filho), conse- 





quentemente ele nào cai na condicional if(cluster.isMaster), Com 
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isso, é iniciado o servidor da aplicação via require("./index.js") para 
este processo filho. 

Também foram incluídos alguns eventos que são emitidos pelo duster 
master. No código anterior, usamos apenas os principais eventos: 


e listening: acontece quando um duster está escutando uma porta do 
servidor. Neste caso, a nossa aplicação está escutando a porta 3000; 

e disconnect: executa seu callback quando um duster se desconecta 
da rede: 


* exit: ocorre quando um processo filho é fechado no sistema operaci- 
onal. 


Desenvolvimento emclusters 


Muito pode ser explorado no desenvolvimento de clusters no Node. js. 
Aqui, apenas aplicamos o essencial para manter nossa aplicação rodando 


em paralelo. Mas, caso tenha a necessidade de implementar mais deta- 
lhes que explorem ao máximo os clusters, recomendo que leia a docu- 
mentação (https-//nodejs.org/api/cluster.html) , para ficar por dentro de 
todos os eventos e funções deste módulo. 





Para finalizar e deixar automatizado o comando npm start que inicia 
o servidor para ele rodar em modo duster, atualize em seu package.json 
o atributo Scripts de acordo com o código a seguir: 


"scripts": ( 


"start": "npm run apidoc && npm run clusters", 
"clusters": "babel-node clusters.js", 

"test": "NODE ENV-test mocha test/»**/*x, js", 
"apidoc": "apidoc -i routes/ -o public/apidoc" 


Pronto! Agora você pode levantar uma rede de dusters de sua aplicação 
pelo comando npm start, 
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11.5 Compactando requisições com GZIP 





Para tornar as requisições mais leves, para consequentemente elas carrega- 
rem mais rápido, vamos habilitar mais um middleware em nossa aplicação 
que será responsável por compactar as respostas JSON e também todos os 
arquivos estáticos da documentação da API para o formato GZIP — um for- 
mato compatível com vários browsers. Vamos fazer essa simples, porém im- 
portante, alteração apenas usando o módulo compression, Instale-o via 
comando: 


npm install compression --save 


Com ele já instalado, será necessário agora apenas incluir sua função 
como middleware no Express. Edite o libs/middlewares,js da seguinte 


maneira: 


import bodyParser from "body-parser"; 
import express from "express"; 

import morgan from "morgan"; 

import cors from "cors"; 

import compression from "compression"; 
import logger from "./logger. js"; 


module.exports - app => 1 
app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(morgan("common", ( 

stream: { 
write: (message) -> 1 
logger.info(message); 


) 
)22; 
app use (cors(( 
origin: ["http://localhost:3001"], 
methods: ["GET", "POST", "PUT", "DELETE"], 
allowedHeaders: ["Content-Type", "Authorization"] 
Ha; 


app.use(compressionO); 
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app.use(bodyParser.json(O); 
app.use(app.auth.initialize()); 
app.use((req, res, next) -> 1 
delete req.body.id; 
next O; 
H; 
app.use(express.static("public")); 
+; 


Para testar essa compactação, basta reiniciar o servidor e, em seguida, 
acessar o endereço da documentação da API (afinal, lá existe muito arquivo 
estático que será compactado para GZIP): http://localhost:3000/apidoc. 


Para visualizar em detalhes, abra o console do browser (Firefox e Google 





Chrome tem um ótimo console client-side) e acesse o menu Redes. Lá você 
verá o tamanho transferido Versus o tamanho do arquivo, semelhante a esta 
figura: 


r] y - 
uH h x 


I M P B uU 
"n mo E u e 


` » 
c 
H 
s 
" 
nan. 
» 





i 


= By'ns transinnidos menores do que a tamanho real dns arquivos 


Fig. 113: Compactação GZIP nas requisições 


11.6 Configurando SSL para usar HTTPS 


Hoje em dia, é mais que obrigação desenvolver uma aplicação segura, que 
forneça uma conexão segura entre cliente e servidor. Para isso, muitas aplica- 
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ções compram e usam certificados de segurança para garantir uma conexão 
SSL (Secure Sockets Layer) por meio do uso do protocolo HTTPS. 

Para implementar uma conexão com protocolo HTTPS em nossa apli- 
cação, é necessário comprar um certificado digital para uso em ambiente de 
produção. No nosso caso, vamos trabalhar com um certificado fictício, não 
válido para uso em produção, e sim somente para fins didáticos. Para criar um 
certificado simples, você pode acessar o site: http://www.selfsignedcertificate. 
com. 

Informe o domínio Ntask da aplicação e clique em Generate. Uma nova 
tela vai aparecer com os dois arquivos de extensão -Key e -cert, Faça 
download desses dois arquivos e mande-os para pasta raiz do nosso projeto. 

Agora vamos utilizar o módulo nativo https para permitir que nosso 
servidor inicie pelo protocolo HTTPS. Para isso, vamos substituir a fun- 
cáo app.listen() pela função https.createServer(credentials, 
app).listen() em nosso arquivo de inicialização da API. Para implemen- 
tar essa funcionalidade, edite o libs/boot.js: 


import https from "https"; 
import fs from "fg": 


module . exports - app -> 1 
if (process.env.NODE ENV !-- "test") ( 
const credentials - { 
key: fs.readFileSync("ntask.key", "utf8"), 
cert: fs.readFileSync("ntask.caert", "utf&") 
) 
app.db.sequelize.sync().done(() -> ( 
https.createServer(credentials, app) 
.listen(app.get("port"), O -> ( 
console.log(C NTask API = porta $[app.get("port"))'); 
BH; 
H); 


Parabéns! Agora sua aplicação estará rodando em um protocolo mais se- 
guro, garantindo que os dados não sejam interceptados. Vale lembrar que, 
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para um projeto em produção, é preciso a compra de um certificado digital, 
jamais utilize esse certificado simples! 


Para testar, basta reiniciar sua aplicação e acessar o endereço: https: 
//localhost:3000/. 


11.7 Blindando a API com Helmet 


Finalizando o desenvolvimento de nossa API, vamos agora incluir um mó- 
dulo muito importante, que é um middleware de segurança que trata vários 
tipos de ataques no protocolo HTTP. Esse módulo se chama helmet, e ele 
é um conjunto de 9 middlewares internos que tratam as seguintes configura- 
ções do HTTP: 


* Configura o Content Security Policy; 


* Remove o header X-Powered-By que informa o nome e versão do 
servidor; 


e Configura regras para HTTP Public Key Pinning; 
* Configura regras para HTTP Strict Transport Security; 


e Trata o header X-Download-Options para IES+: 


Desabilita client-side caching; 


Previne ataques do tipo Sniffing no Mime Type do cliente; 


Previne ataques do tipo ClickJacking; 


* Protege contra ataques do tipo XSS (Cross-Site Scripting). 


Em resumo, mesmo que vocé nào entenda muito sobre seguranga, utilize- 
o, pois, além de ter uma simples interface, ele vai blindar sua aplicação web 
contra diversos tipos de ataques sobre o protocolo HTTP. Para instalá-lo, rode 
o comando: 


npn install helmet --save 
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Para garantir total segurança em nossa API, vamos usar todos os 
9 middlewares do helmet, que é facilmente incluído via função 


app.use(helmet0). Então, edite o código libs/middlewares.js 


com a seguinte implementação: 


import bodyParser from "body-parser"; 
import express from "express"; 

import morgan from "morgan"; 

import cors from "cors"; 

import compression from "compression"; 
import helmet from "helmet"; 

import logger from "./logger.js"; 


module.exports - app -> 1 
app.set("port", 3000); 
app.set("json spaces", 4); 
app.use(morgan("common", 1 
stream: { 
write: (message) -> { 
logger.info(message); 
) 
) 
HW); 
app .use (helmet ()); 
app . use (cors(f 
origin: ["http://localhost:3001"], 
methods: ["GET", “POST”, "PUT", "DELETE"], 


allowedHeaders: ["Content-Type", "Authorization"] 


)22; 

app . use (compression()); 

app .use (bodyParser. json()); 

app .use (app. auth initialize O); 

app .use((reg, res, next) -> 1 
delete reg. body. id; 
next(); 

Ds 

app . use (express. static("public")); 

}; 
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Agora, reinicie sua aplicação e acesse pelo browser o endereço: http:// 


localhost:3000/. 
Abra o console do browser e, no menu Redes, visualize em detalhes os 


dados requisição da GET /. Lá você verá novos itens incluídos no cabeçalho 


de resposta, algo semelhante a esta figura: 
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Fig. 114: Headers de segurança 


Conclusão 


Congrats! Acabamos de finalizar o desenvolvimento completo de nossa 
API! Você pode usar esse projeto como base para seus futuros projetos de 
API Node.js, pois foi desenvolvida, na prática, uma API documentada que 
adota os principais padrões RESTful, possui testes em cima dos endpoints, 
persiste dados em banco de dados do tipo SQL via módulo Sequelize e, o 
mais importante, segue boas práticas de performance e segurança para rodar 





em ambiente de produção. 
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Mas calma! O livro ainda nào acabou! Nos próximos capítulos, criaremos 
uma aplicação web que vai consumir dados da API. Ela será uma simples SPA 
(Single Page Application), e será desenvolvida utilizando apenas o mais puro 
do JavaScript ES6, por meio do uso dos módulos browserify e babel no 


front-end. 
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Construindo uma aplicação 
cliente — Parte | 


Depois de uma longa leitura sobre como construir um back-end de API 
RESTful utilizando Node.js e algumas boas práticas de desenvolvimento com 
a linguagem JavaScript EcmaScript 6, vamos criar, a partir deste capítulo, um 
novo projeto. Dessa vez, um projeto front-end usando o melhor do JavaScript 
EcmaScript 6! 

Este livro apresentou 80% de conteúdo sobre desenvolvimento back-end, 
mas somente agora, neste capítulo, focaremos nos 20% de conteúdo front- 
end. Afinal, temos uma API, porém ela ainda não possui uma aplicação cli- 





ente, e os usuários somente interagem com aplicações clientes. 
Por este motivo, nestes últimos capítulos, construiremos uma aplicação 
SPA (Single Page Application), utilizando apenas boas práticas de JavaScript 
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puro. Isso mesmo! Apenas JavaScript ES6! 

Não será usado nenhum framework de front-end (Angular, Backbone, 
Ember, React etc.), e também não será utilizado jQuery para manipulação 
do DOM (Document Object Model) do HTML. Apenas o melhor do Vanilla 
JavaScript! 


12.1 Setup do ambiente da aplicação 


A nossa aplicação cliente será construída utilizando boas práticas de Orien- 
tação a Objetos (OO) do ES6, e Browserify para usar no front-end alguns 
módulos do NPM. Também vamos automatizar algumas tarefas de build da 
aplicação utilizando apenas comando alias do NPM, que é algo que foi usado 
bastante na construção da API. 

Para começar essa brincadeira, vamos abrir o terminal em uma pasta 
qualquer de workspace de sua preferência. Não pode ser no mesmo diretório 
da API, pois esse será um novo projeto que vamos construir do zero. 

Para iniciar este novo projeto, que será chamado de ntask-web, vamos 
rodar os seguintes comandos: 


mkdir ntask-web 
cd ntask-web 
npm init 


Com o comando Nem 1n11t, vamos responder as seguintes perguntas: 
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L4 o 


[cororntask-wmeb] $ npm init 
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Fig. 12.1: Descrição do package.json do NTask Web 


Após a execução do Npm init, surgiu o arquivo Package.json do 
nosso novo projeto. Crie na raiz do projeto os seguintes diretórios pelos co- 
mandos: 


mkdir -p public/(css,fonts, js} 
mkdir -p src/(components,templates) 


No final, teremos a seguinte estrutura de diretórios: 


e public: pasta para arquivos estáticos; 


e public/css: diretório de CSS (vamos usar o CSS do Ionic); 
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e public/fonts: diretório de fontes (vamos usar os fonticons do Io- 
nic); 


e public/js: diretório de JavaScript, aqui terá a versão final (compilada 
e minificada) do código JavaScript da nossa aplicação cliente; 


e SFC: pasta com códigos JavaScript separado em módulos; 


e Src/components: pasta com códigos JavaScript de regras de negócio 
de cada página da aplicação; 


e src/templates: pasta com códigos de templates (páginas da aplica- 
ção), que são Strings representando pedaços de HTML concatenados 
com dados de objetos que serão enviados pela API. 


Agora, vamos instalar todos os módulos que serão utilizados em nossa 
aplicação cliente. Usaremos os seguintes módulos: 


e http-server: CLI de servidor HTTP para arquivos estáticos (afinal, 
nossa aplicação cliente será construída apenas com HTML, CSS e Ja- 
vaScript). 


e browserify: um compilador JavaScript que permite utilizar módulos 
do NPM que são construídos com código JavaScript isomórfico (são 
códigos que funcionam tanto no back-end como no front-end), assim 
como também permite carregar códigos JavaScript no padrão Com- 
monJS, o mesmo padrão do Node.js. 


e babelify: um plugin para o browserify, baseado no Babel, para com- 
pilar códigos EcmaScript 6 no front-end. 


e Uglify: módulo que simplesmente faz minificação de código JavaS- 
cript. 


e tiny-emitter: um módulo pequeno que permite implementar e tra- 
balhar de forma orientada a eventos. 


e browser-request: é uma versão do módulo request focado para 
browsers, ele é cross-browser (compatível com os principais browsers) 
e abstrai toda complexidade de realizar uma requisição AJAX. 
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Basicamente, vamos construir um cliente web usando apenas esses mó- 
dulos. Então, instale-os com os comandos: 


npm install http-server browserify babelify --save 
npm install uglify tiny-emitter browser-request --save 


Após essa instalação, vamos modificar o package.json removendo os 
atributos main, script.teste license e adicionando todos os coman- 
dos alias que serão necessários para fazer um build do projeto front-end. 


Basicamente, vamos: 


* Criar alias para minificar código JavaScript pelo nem run uglify; 


e Compilar e concatenar todos códigos da pasta SFC via browserify por 
meio do comando npm run browserify: 


* Iniciar o servidor na porta 3001 através do npm run server; 


e Gerar build da aplicação front-end (junção dos comandos NPM run 


browserify e Nom run uglify) pelo novo comando npm run 
build. 


e Criar o comando Npm Start, que é a execução dos comandos Nem 
run build e npm run server, 


Para aplicar essas alterações, edite o package.json para que ele fique 
exatamente igual a este: 


[ 

"name": "ntask-web", 

"version"; "1.0.0", 

"description": "Versão web do gerenciador de tarefas", 

"scripts"; ( 
"start": "npm run build && npm run server", 
"server": "http-server public -p 3001", 
"build": "npm run browserify && npm run uglify", 
"browserify": "browserify src -t babelify 


=0 public/js/app. js", 
"uglify": "uglify -s public/js/app.js 
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-0 public/js/app.min, js" 
A 
"author": "Caio Ribeiro Pereira', 


"dependencies": ( 


"babelify": "^6,3,0", 
"browser-request": "70.3.3", 
"browserify"; "^11.2.0", 
"http-server": "^0,8.4", 
"tiny-emitter": "^1.0.0", 
"uglify": "^0.1.5" 


Após esse setup do ambiente da aplicação, incluiremos alguns arquivos 
estáticos que serão responsáveis pela estilização do layout e do conteúdo ini- 
cial da homepage do nosso projeto. Para nào perder tempo, vamos utilizar 
uma estilização de CSS pronta, do framework Ionic, um framework muito 
legal que possui diversos componentes mobile para construção de aplicações 
web responsiva. 

Nào vamos usar o framework completo do Ionic, afinal, ele possui uma 





forte dependéncia do framework Angular. Vamos apenas incluir seu CSS e 
pacote de ícones. Para 1sso, recomendo que você faça o download dos ar- 
quivos que listarei a seguir e, em seguida, envie os arquivos de CSS para o 
diretório public/css, e os arquivos de fontes para public/fonts: 


e CSS dolonic: 
http://code.ionicframework.com/1 .0.0/css/10nic.min.css 
* CSS do lonic icons: 


http://code.ionicframework.com/ionicons/2.0.0/css/1onicons.min.css 


e Fontes do lonic Icons: 


http://code.ionicframework.com/1 .0.0/fonts/10nicons.eot 
http://code.ionicframework.com/1 .0.0/fonts/ionicons.svg 
http://code.ionicframework.com/1 .0.0/fonts/1ionicons.ttf http: 
//code.ionicframework.com/1.0.0/fonts/10nicons.woff 
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Assim, criaremos a página inicial e código JavaScript para testarmos o 
comando nem Start que inicializa a aplicação. O HTML principal será 
responsável por carregar a estilização CSS do Ionic, o JavaScript principal das 
interações da aplicação, e também terá o mínimo de tags HTML para mon- 





tar a estrutura do layout. Para entender essa implementação, crie o arquivo 
public/index.html da seguinte maneira: 


!IDOCTYPE html» 
chtml> 
<head> 
«meta charset-"utf-3"-» 
*title»NTask = Gerenciador de tarefas-/titlo» 
*meta name-"viewport" 
content-"wyidth-device-width,initial-scale-1"» 
«link rel-"stylesheet" href-"css/ionic,.min.css"» 
«link rel-"stylesheet" href-"css/ionicons,.min.csg"»? 
<script src-"js/app.min. js" async defer></script> 
<ihead> 
<body> 
«header class-"bar bar-header bar-calm"-» 
<hi class-"title"»NTask:/h1»? 
</header> 
<div class-"scroll-content ionic-scroll"^ 
«div class-"content overflow-scroll has-header"» 
cmain></main> 
<footer></footer> 
</div> 
c/div» 
</body> 
</html> 


Perceba que existem duas tags vazias: a  <main></main> e a 
«footer» «/footer» . Todas as regras de interação da aplicação serão cria- 
das para manipular essas tags de forma dinâmica por meio dos futuros códi- 





gos JavaScript que vamos escrever em breve. 

Para finalizar essa seção inicial, crie o. Src/index.js com um có- 
digo que, por enquanto, exibirá uma simples mensagem de Bem-vindo! 
no browser quando carregar a página. Isso será modificado em breve, afinal, 
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vamos criá-lo agora apenas para testar se o ambiente da aplicação está funci- 
onando corretamente. 


window.onload - O -> 1 
alert("Bem-vindo!"); 
); 


Pronto. Agora já temos um ambiente simples, porém funcional, para 
construirmos o front-end da aplicação NTask Web. Para testá-lo, execute 
o comando Npm Start e, em seguida, acesse o endereço: http://localhost: 
3001. 

Se tudo estiver funcionando direito, você terá o seguinte resultado: 


“... C um oa e. 


nano 8 


E 
I 
| 


| 5 uestem 








Fig. 122: Primeira tela do NTask Web 


122 Criando Templates de Signin e Signup 


Nesta seção, vamos criar todos os templates que serão utilizados em nossa 
aplicação cliente. Os templates são basicamente pedaços de HTML, mani- 
pulados via JavaScript, e são largamente utilizados em sistemas do tipo SPA 
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(Single Page Application, ou seja, aplicações de uma única página). Afinal, 
a filosofia de uma SPA é carregar todos os arquivos estáticos uma única vez 
(HTML, CSS, JavaScript, imagens etc.), para que somente os dados sejam re- 
quisitados com frequência do servidor. 

Toda responsabilidade de transição de telas (transição de templates) e 
concatenação de dados do servidor com as telas se tornam tarefas da apli- 
cação cliente, fazendo com que o servidor trafegue apenas dados, e o cliente 
trate de pegar os dados para montar as devidas telas para o usuário final inte- 
ragir na aplicação. 

Nossa aplicação é um simples gerenciador de tarefas, que possui uma API 
REST com endpoints para criar; atualizar; excluir e listar tarefas; e cadastrar, 
consultar e excluir um usuário. Os templates serão baseados nessas funcio- 
nalidades que a API fornece atualmente. Então, não há nada a inventar, e sim 
botar a mão na massa baseado nos endpoints da API 

Para começar, vamos construir o template que será a tela de Sign in e sign 
Up da aplicação. Graças à funcionalidade de Template String do EcmaScript 
6, se tornou possível criar strings com concatenação de dados de forma mais 
elegante através da sintaxe “Olá $(nome);, Com isso, não será necessário 
usar nenhum framework de template engine, pois podemos facilmente criar 
os templates utilizando apenas uma função que retorna uma string de HTML 
concatenada com dados. 

Para entender melhor essa implementação, vamos começar criando a 
tela inicial de sign in que, por meio da função  render?(, retornará 
uma String de HTML, ou seja, o template da tela sign m. Crie o arquivo 
src/templates/signin.js com o seguinte código: 


exports.render = () -> { 
return `<form> 
<div class-"list"» 

<label class=" item item-input item-stacked-labe1"> 
«span class—"input-label">Email</span> 
<input type="text" data-email> 

</label> 

<label class-"item item-input item-stacked-labe1"> 
«span class-"input-label"»Senha*/span» 


<input type-"password" data-password> 
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</label> 
</div> 
<div class-"padding"> 
«button class-"button button-positive button-block"» 
«i class-"ion-home"»«/i» Entrar 
</button> 
</div> 
</form> 
<div class-"padding"» 
«button class-"button button-block" data-signup> 
«i class-"ion-person-add"»«/i» Cadastrar 
</button> 
</div>"; 
+; 


Agora, para completar o fluxo, vamos criar também o template da tela de 
sign up (cadastro de usuário). Crie o arquivo Src/templates/signup.jJs 


da seguinte maneira: 


exports.render = () -> 1 
return <form> 
«div class-"list"» 
«label class-"item item-input item-stacked-label"» 
«span class-" input-labol">Nome</span> 
<input type-"text" data-name> 
</label> 
«label class-"item item-input item-stacked-label"» 
<span class-"input-labol"»Emailc/span» 
«input type-"text" data-email» 
«/label» 
«label class-"item item-input item-stacked-label"? 
«span class-"input-label"»Senhac/span-» 
<input type-"password" data-password» 
</label> 
</div> 
«div class-"padding"> 
<button class-"button button-positive button-block"> 
<i class-"ion-thumbsup"»«/i» Cadastrar 
</button> 
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Pronto! Já temos duas telas importantes da aplicação. Agora, só falta cri- 
armos os códigos de interação dessas páginas. Eles serão responsáveis por 
renderizar esses templates e, principalmente, programar os eventos de cada 
componente do template, para que eles realizem suas devidas comunicações 
com a API. 


12.3 Implementando os componentes de sign in e 
sign up 


Os códigos de interação dos templates serão colocados na pasta 
src/components, mas antes de criá-los, vamos explorar duas novas 
funcionalidades do JavaScript ES6: classes e herança. Para deixar mais 
semántico e organizado, criaremos uma classe pai que terá apenas dois 
atributos importantes que todas as classes de componentes vào herdar: 
this.URL (aqui terá o endereco URL da API) e this.request (aqui será 
carregado o módulo browser-request), 

Outro detalhe dessa classe pai é que ela vai herdar todas as funciona- 
lidades do módulo tiny-emitter (via linha class NTask extends 
TinyEmitter), que repassará essas funcionalidades também para suas clas- 
ses filhas, permitindo que elas emitam e escutem os eventos. Para entender 
melhor essa classe, crie o arquivo Src/ntask.js: 
import TinyEmitter from "tiny-emitter"; 
import Request from "browser-request"; 


class NTask extends TinyEmitter ( 
constructor() { 
super O; 
this.request - Request; 


[SARA 


this.URL - "https ://localhost:3000"; 


} 
module, exports - NTask; 
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Agora que temos a classe pai NTask, torna-se possível construir as clas- 
ses de componentes que, não só terão suas funcionalidades específicas, como 
também terão atributos e funções genéricas herdadas da classe pai. Ou seja, 
os componentes, em vez de duplicar ou triplicar códigos, eles vào reaproveitar 
códigos. 

Vamos criar nosso primeiro componente, que será a tela de sign in. O pa- 
drão das classes dos componentes de nossa aplicação terá sempre um constru- 
tor recebendo um objeto body ( constructor(body)). Esse body será 


basicamente o objeto DOM da tag «main», ou tag «footer» da página 





principal, tudo vai depender do que será esse componente. 

Todos os componentes vão herdar da classe pai NTask, logo, é obriga- 
tório a execução da função SU per( no início do construtor da classe filha. 
Outro padrão que vamos adotar para organizar os nossos componentes será 
o uso dos métodos: renderQ (responsável por renderizar um módulo de 
template) e addEventListener( (responsável por fazer um escuta e tra- 
tamento dos eventos de botões, links ou formulários, ou seja, componentes 
do HTML dos templates). 

Neste caso, teremos dois eventos encapsulados nos métodos: 
formSubmit() (responsável por fazer uma requisição de autenticação 
de usuário na API) e signupClick() (responsável por mostrar o template 
da tela de cadastro, a tela de sign up). 

Todaresposta final de um componente do template deve emitir um evento 
pela função this.emit("nome-do-evento"), pois vamos criar em breve 
uma classe observadora de eventos que será responsável por delegar tarefas 
entre os demais componentes, de acordo com os eventos emitidos. Um bom 
exemplo de tarefas que será largamente usada é a de transição entre templates, 
que ocorre quando um usuário clica no botão de um template e, no evento de 
click, a classe observadora delega a tarefa para um novo template renderizar 
sua tela. 

Para entender melhor essas regras, crie © arquivo 
src/components/signin.js com os seguintes códigos: 


import NTask from "../ntask. js"; 
import Template from "../templates/signin.js"; 
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class Signin extends NTask ( 
constructor (body) ( 
super O; 
this.body - body; 
) 
render() 1 
this.body.innerHTML = Template.render(); 
this.body.querySelector(" [data-email]").focusO; 
this.addEventListener (); 
) 
addEventListener() 1 
this.formSubmit(); 
this.signupClickO; 
) 
formSubmit() 1 
const form - this.body.querySelector ("form"); 
form.addEventListener("submit", (e) -> ( 
e. preventDefault(); 
const email - e.target.querySelector(" [data-email]"); 
const password - e.target.querySelector("[data-password]"); 
const opts - 1 
method: "POST, 
url: ^"$(this.URL)/token', 
json: true, 
body: { 
email: email,value, 
password: password.value 
) 
k; 
this.request(opts, (err, resp, data) -> 1 
if (err || resp.status --- 401) ( 
this. emit("error", err); 
) else 1 
this.emit("signin", data.token); 


signupClick() { 
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const signup - this.body.querySelector("[data-signup]"); 
signup .addEventListener("click", (e) -> { 
e.preventDefault (); 
this .emit("signup"); 
2 


) 
module . exports - Signin; 


Também criaremos a classe de componentes do Signup, Ela seguirá o 
mesmo padrão da classe 5!9nin, Para ver como que ela deve ficar, crie o 
src/components/signup.js da seguinte forma: 


import NTask from ",./ntask. js"; 
import Template from "../templates/signup.js"; 


class Signup extends NTask { 
constructor (body) { 
super (); 
this.body = body; 
} 
render () { 
this.body.innerHTML - Template,render (); 
this, body. querySelector(" [data-name]") focus O ; 
this. addEventListener (); 
) 
addEventListener() 1 
this.formSubmit(); 
) 
formSubmit() 1 
const form - this.body.querySelector ("form"); 
form. addEventListener ("submit", (e) -> { 
e. preventDefault (); 
const name - e.target.querySelector (" [data-name]"); 
const email - e.target .querySelector(" [data-email]"); 
const password - e.target .querySelector (" [data-password]"); 
const opts - 1 
method: "POST", 
url: "$(this.URL)/users', 
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json: true, 
body: { 
name; name,value, 
email: email.value, 
password: password, value 
) 
k; 
this.request(opts, (err, resp, data) -> { 
if Cerr || resp.status --- 412) ( 
this.emit("error", err); 
) else 1 
this. emit("signup", data); 


module. exports - Signup; 


Para finalizar esse fluxo inicial da aplicação, falta apenas criar a classe 
observadora e, em seguida, carregá-la dentro do src/index.js, que é o 
código responsável por iniciar toda interação dos componentes. A classe ob- 
servadora se chamará App. Seu construtor realizará a instância de todos os 





objetos componentes, e ela terá dois métodos principais: o INItTO (respon- 
sável por iniciar os componentes) e addEventListener() (responsável 
por escutar e tratar os eventos dos componentes). 

Para que nossa aplicação apresente as primeiras interações de tela de sign 
in e sign up, crie o Src/aPP.js, seguindo esse código inicial: 


import Signin from "./components/signin.js"; 
import Signup from "./components/sigmup. js"; 


class App 1 
constructor (body) { 
this.signin - new Signin(body); 
this.signup - new Signup(body); 
) 
init() { 
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this.signin.render(); 
this. addEventListener (); 


) 
addEventListener () 1 
this. signinEvents ()D; 
this. signupEvents (D; 
) 
signinEvents() { 
this.signin.on("error", () -> alert ("Erro de autenticação")); 
this.signin.on("signin", (token) -> ( 
localStorage .setItem("token", 'JWT $(token)')D; 
alert("Vocé esta autenticado!"); 
p; 
this.signin.on("signup", () -> this.signup.render ()); 
) 
signupEventsO 1 
this.signup.on("error", () -> alert("Erro no cadastro")); 
this.signup.on("signup", (user) -> ( 
alert(" $&(user.name) você foi cadastrado com sucesso!'); 
this.signin.render(); 


+); 


) 
module,.exports - App; 


Basicamente foram criados os eventos de sucesso na autenticação, erro 
na autenticação, acesso à tela de cadastro, sucesso no cadastro e erro no ca- 
dastro. O método INITtO inicia renderizando a tela inicial, que é a tela de 
sign in e, em seguida, executa o método addEventListener(), para escu- 
tar todos os eventos dos componentes que estão encapsulados nos métodos 
signinEvents() e signupEvents(), 

Para finalizar, vamos editar o src/index.js para que, por meio do 
evento Window.onload(), ele inicie a classe APP para dar início a todo o 
fluxo interativo da aplicação. Edite-o da seguinte maneira: 


import App from "./app.js" 


window.onload - (O) -> ( 
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const main - document. querySelector ("main"); 
new App (main). init(); 
}; 


Vamos testar? Se você seguiu passo a passo essas primeiras implementa- 
ções, você terá um fluxo básico de sign in e sign up. Para rodar a aplicação, 
será necessário ter duas abas de terminal abertas: uma para iniciar o servi- 
dor da API através do comando "pm start, e outra na pasta desse projeto 
cliente. 

Execute também o comando Npm start, Se tudo estiver rodando cor- 
retamente, você terá dois endereços disponíveis: 


e Endereço da API: https://localhost:3000 


* Endereço do cliente web: http://localhost:3001 


Como estamos usando um certificado digital nào válido para produção, 
é bem provável que seu browser bloqueie o acesso à API. Caso isso aconteça, 
basta acessar o endereço: https://localhost:3000/. 

Depois, procure em seu browser como adicionar exceção ao acesso à 
nossa API. Veja na figura seguir, como adicionar exceção, por exemplo, no 
Mozilla Firefox: 
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Como estamos usando um certificado falso. e provavel que seu browser nao permita 
0 acesso, neste caso acesse o endereço da API e adicione uma exceção 


Fig. 123: Adicionando exceção ao acesso à API 


Agora que a API esta com acesso permitido pelo seu browser, acesse o 
endereço do cliente web: http://localhost:3001. 
Se tudo estiver correto, vocé terá acesso às seguintes telas: 


Fig. 124: Tela inicial de Signin 
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Fig. 12.5: Tela de cadastro de usuário 





Fig. 12.6: Cadastrando um novo usuário 
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Fig. 12.7: Logando com nova conta cadastrada 


Conclusão 


Nosso novo projeto está ganhando forma, e estamos cada vez mais próxi- 
mos de construir um sistema funcional para o usuário final, tudo isso através 
da integração da aplicação cliente com a API que já foi construída capítulos 
atrás. 

Neste capítulo, foi criado apenas o ambiente e algumas telas do projeto, 
suficiente para estruturar o front-end da aplicação NTask. Continue lendo, 
pois no próximo capítulo vamos aprofundar mais na implementação das telas 


finais. 
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Construindo uma aplicação 
cliente — Parte 2 


Dando continuidade à construção da aplicação cliente, até agora temos uma 
aplicação com layout, que apenas se conecta à API e permite autenticar um 
usuário para acessar a aplicação cliente. Neste capítulo, vamos construir as 
funcionalidades principais para gestão de tarefas do usuário autenticado. 


13.1 Templates e componentes para CRUD de ta- 
refas 
A construção do template de tarefas será um pouco complexa, porém terá um 


resultado final bem legal! Esse template terá de listar todas as tarefas existen- 
tes de um usuário, então sua função receberá como argumento uma lista de 
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tarefas e, por meio da função tasks.map(Q, será criado um array de tem- 
plates referente a cada tarefa. 





No final da geração desse novo array, é executada a função Join (^^), 
que será responsável por concatenar todos os seus itens em uma ünica 
string de template das tarefas. Para facilitar essa manipulação e gera- 
ção do template de tarefas, essa lógica será encapsulada através da função 
renderTasks(tasks), pois o retorno desta será concatenado em uma 
string de template final, responsável por verificar se existem tarefas para exibir 
todas as tarefas. Caso contrário, mostrará uma mensagem de que não existe 
nenhuma tarefa. 


Para entender melhor a implementação desse template, crie o arquivo 
src/templates/tasks.js da seguinte maneira: 


const renderTasks - tasks -> { 
return tasks map (task -> ( 
let done = task.done ? "ios-checkmark" 
nios-circle-outline"; 
return '«li class-"item item-icon-left item-button-right"» 
«i class-"icon ion-$&(done)" data-done 
data-task-done-"$(task.done ? 'done?* ; *'?*j" 
data-task-id-"$(rtask.id)"»«/i» 
$(task,title] 
«button data-remove data-task-id-"$(task.id)" 
class-"button button-assertive"» 
«i class-"ion-trash-a"»«/i» 
</button> 
</li>’: 
)3.10i1n("* "3; 
); 
exports,render - tasks -> 1 
if (tasks && tasks.length) { 
return '«ul class-"list"»$[(renderTasks(tasks)]-/ul»^'; 
} 
return `<h4 class-"text-center'"»Nenhuma tarefa ainda</h4>'`; 
+; 


É por meio dos atributos  data-task-done, — data-task-id, 


data-done e data-remove, que trabalharemos para criar o compo- 
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nente de manipulação de tarefas. Esses atributos serão usados para criar 
os eventos necessários, para permitir excluir uma tarefa (via método 
taskRemoveClick()) e/ou definir que tal tarefa foi concluída (via método 

taskDoneCheckbox()). Essas lógicas de interação desse template serão es- 

critas no Src/components/tasks.js a seguir: 


import NTask from ",./ntask. js"; 
import Template from ",./templates/tasks. js"; 


class Tasks extends NTask { 
constructor (body) 1 
super (); 
this.body - body; 
) 
render() 1 
this.renderTaskList(); 
) 
addEventListener() 1 
this.taskDoneCheckbox(); 
this.taskRemoveClick(); 
} 
renderTaskList() { 
const opts - { 
method: "GET", 
url; `${tħis, URL}/tasks'`, 
json: true, 
headers: { 
authorization: localStorage .getItem("token") 
} 
$i 
this.request(opts, (err, resp, data) -> { 
if (err) 1 
this.emit("error", err); 
] else { 
this.body.innerHTML - Template.render (data); 
this.addEventListener (O; 


Bs 
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taskDoneCheckbox() 1 
const dones - this.body.querySelectorA11(" [data-done]"); 
for(let i - 0, max - dones.length; i < max; i++) ( 
dones[i].addEventListener("click", (e) -> ( 
e. preventDefault(); 
const id - e.target.getAttribute("data-task-id"); 
const done ~ e.target.getAttribute("data-task-done"); 
const opts - { 
method: "PUT", 
url: "$(this.URL)/tasks/$[id)', 
headers: 1 
authorization: localStorage.getItem("token"), 
"Content-Type": "application/json" 
F, 
body; JSON.stringify(( 
done: !done 
}) 
}; 
this.request(opts, (err, resp, data) -> { 
if (err || resp.status --- 412) { 
this.emit("update-error", err); 
] else { 
this.emit("update"); 


taskRemoveClick() { 
const removes - this.body.querySelectorAll(" [data-remove]"); 
for(let i - 0, max - removes.length; i < max; i++) ( 
removes[i].addEventListener("click", (e) -> { 
e.preventDefault(); 
if C(confirm("Deseja excluir esta tarefa?")) { 
const id - e.target.getAttribute("data-task-id"); 
const opts = 1 
method: "DELETE", 
url: '"$íthis.URL)/tasks/$[id)', 
headers: { 
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authorization: localStorage .getItem("token") 


) 
k; 
this.request(opts, (err, resp, data) -> 1 
if Cerr || resp.status --- 412) { 
this.emit("remove-error", err); 
) else { 
this.emit("remove"); 
) 
H3 
} 
A 


module . exports - Tasks; 


Agora que temos um componente responsável por listar, atualizar e ex- 
cluir uma tarefa, vamos implementar o template e componente responsá- 
vel por adicionar uma nova. Isso será mais fácil de criar, pois será um 
template com um simples formulário para cadastrar uma tarefa e, no fi- 


nal, redirecionará para uma lista de tarefas. Para criá-lo, crie o arquivo 
src/templates/taskForm Js: 


exports.render - () -> ( 
return <form> 
«div class-"list"» 
«label class-"item item-input item-stacked-label"» 
<span class-"input-label'>Tarefa</span> 
<input type-"text" data-task> 
</label> 
</div> 
<div class-"padding"» 
«button class-"button button-positive button-block"> 
«i class-"ion-compose"»«/i» Salvar 
</button> 
</div> 
</form>"; 
}; 
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Em seguida, crie o seu respectivo componente que terá apenas o evento 
de submissão do formulário encapsulado pela função formSubmit(). Para 
criá-lo, crie o arquivo Src/com ponents/taskForm Js: 


import NTask from ",./ntask, js"; 
import Template from "../templates/taskForm,. js"; 


class TaskForm extends NTask { 
constructor (body) { 
super O; 
this.body - body; 
) 
render() 1 
this.body.innerHTML - Template.render(); 
this.body.querySelector("[data-task]").focusQO; 
this.addEventListener (); 
) 
addEventListener O) 1 
this.formSubmit(); 
) 
formSubmit() 1 
const form ~ this.body.querySelector("form"); 
form,.addEventListener("submit", (e) -> 1 
e.preventDefault(); 
const task - e.target .querySelector (" [data-task]"); 
const opts - { 
method: "POST", 
url: '"$íthis,URL)/tasks', 
json: true, 


headers: { 
authorization: localStorage.getlItem("token") 
), 
body: 1 
title: task,value 
) 
); 
this.request(opts, (err, resp, data) -> 1 
if Cerr || resp.status --- 412) ( 


this.emit("error"); 
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) else { 
this.emit("zsubmit"); 


module.exports - TaskForm; 


132 Componentes para tela de usuário logado 


Para terminar a criação de telas da nossa aplicação, vamos construir a última 


tela que exibirá dados do usuário logado e um botão para ele cancelar a conta 
na aplicação. Essa tela também terá um componente fácil de implementar, 
pois precisará apenas tratar o evento do botão de cancelamento de conta. Para 
criá-la, primeiro crie o Src/templates/user;js: 


exports.render - user -> ( 
return '«div class-"list"» 
«label class-"item item-input item-stacked-label"» 
<span class-"input-label"»Nomec/span» 
«small class-"dark'"»$[user.name]«/small» 
</label> 
«label class-"item item-input item-stacked-label"» 
«span class-"input-label"»Emailc/span» 
«small claas-"dark"»$í[user.email)«/small»? 
</label> 
</div> 
<div class-"padding"» 
«button data-remove-account 
class-"button button-assertive button-block"> 
«i class-"ion-trash-a"»«/i» Excluir conta 
</button> 
</div>"; 
); 





Agora que temos o template da tela de usuário, crie seu respectivo com- 
ponente pelo arquivo Src/components/user.Js, seguindo essa imple- 


mentação de código: 
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import NTask from "../ntask.js"; 
import Template from "../templates/user.js"; 


class User extends NTask ( 
constructor (body) { 
super (); 
this.body = body; 
) 
render() 1 
this.renderUserData(); 
) 
addEventListener() 1 
this.userCancelClickO; 
) 
renderUserData() 1 
const opts - 1 
method: "GET", 
url: "$í(this.URL)/user', 
json: true, 
headers: f 
authorization: localStorage.getItem("token") 
) 
ur 
this.request(opts, (err, resp, data) -> 1 
if (err || resp.status --- 412) 1 
this.emit("error", err); 
} else ( 
this.body.innerHTML - Template.render (data); 
this,.addEventListener OQ; 


p; 
) 
userCancelClick() { 
const button - 
this.body.querySelector(" [data-remove-account]"); 
button.addEventListener("click", (e) -> ( 
e.preventDefault (); 
if (confirm("Tem certeza que deseja excluir sua conta?")) 1 
const opts - { 
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method: "DELETE", 
url: ^$íthis.URL)/user', 


headers: { 
authorization: localStorage.getItem("token") 
) 
); 
this.request(opts, (err, resp, data) -> ( 
if Cerr || resp.status --- 412) 1 
this.emit("remove-error", err); 
) else { 
this.emit("remove-account"); 
) 
}); 
} 
H; 


module. exports - User; 


13.3 Criando componente de menu da aplicação 


Para deixar a aplicação mais bonita e interativa, vamos também criar em 
seu rodapé um menu para que o usuário acesse a lista de tarefas, o formu- 


lário para cadastro de nova tarefa ou a tela de dados do usuário. Para criar 


essa tela, primeiro criaremos o seu template, que inicialmente terá três bo- 





tões: lista de tarefas, cadastro de tarefa e logout da aplicação. Crie o arquivo 


src/templates/footerjs da seguinte maneira: 


exports.render - path -> { 


let isTasks - path —- "tasks" ? "active" ; ""; 

let isTaskForm - path --- "taskForm" 7 "active" ; nn; 
let isUser - path -— "uger" 7 "active" ; ""; 

return ' 


«div class-"tabs-striped tabs-color-calm"» 
«div class-"tabs"» 


«a data-path-"tasks" class-"tab-item $[(isTasks)"» 


«i clags-"icon ion-home"»«/i» 
</a> 
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«a data-path-"taskForm" class-"tab-item $[isTaskForm]"» 


«i class-"icon ion-compose"»«/i» 
</a> 
«a data-path-"user" class-"tab-item &(isUser)"> 
«i class-"icon ion-person"»«/i» 
</a> 
«a data-logout class-"tab-item"» 
«i class-"icon ion-android-exit'"»«/i» 
</a> 
</div> 
</div>"; 


Em seguida, crie seu respectivo componente, 
src/components/menu Js: 


import NTask from "../ntask. js"; 
import Template from "../templates/footer.js"; 


class Menu extends NTask { 

constructor (body) { 
super (); 
this.body - body; 

) 

render(path) 1 
this.body.innerHTML - Template.render (path); 
this. addEventListener (); 


) 

clear() 1 
this.body.innerHTML - ""; 

} 


addEventListener() f 
this.pathsClickO; 
this. logoutClick(); 

) 

pathsClickO 1 


const links - this.body.querySelectorAl11(" [data-path]"); 


for(let i - 0, max - links.length; i < max; i++) { 
links[i].addEventListener("click", (e) -> { 
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e.preventDefault (); 
const link ~ e.target.parentElement; 
const path - link .getAttribute("data-path'"); 
this.emit("click", path); 
)); 


) 
logoutClick(O 1 
const link - this .body.querySelector("[data-logout]"); 
link.addEventListener("click", (e) -> { 
e.preventDefault(); 
this,emit("logout"); 
+) 


) 


module,exports - Menu; 


134 Tratando os eventos dos componentes das 
telas 





Nosso projeto possui todos os componentes necessários para construir uma 
aplicação de gestão de tarefas, tudo o que falta agora é juntar as peças do 
quebra-cabeça! A começar, vamos modificar o src/index.js para que ele 
manipule, não só a tag «main», mas também a <footer>, pois essa nova 
tag será usada no menu da aplicação. 

Edite o Src/index.js aplicando essa simples modificação: 


import App from "./app.js" 


window.onload - (O) -> 1 
const main - document. querySelector ("main"); 
const footer - document .querySelector("footer"); 
new App(main, footer).initO; 


$5 


Agora, para finalizar nosso projeto, temos de atualizar o objeto APP para 
que ele seja responsável por carregar todos os componentes que foram criados 





e, principalmente, tratar os eventos de cada componente. Isso para garantir 
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o fluxo correto de transição das telas, do menu e do tráfego de dados entre 
o ntask-api com ntask-web, Para isso, edite o SrC/app.js com o 


seguinte código: 


import Tasks from "./components/tasks.js"; 
import TaskForm from "./components/taskForm. js"; 
import User from ",/components/user, js"; 

import Signin from "./components/sigmnin. js"; 
import Signup from "./components/sigmup. js"; 
import Menu from "./components/menu. js"; 


class App { 
constructor(body, footer) 1 
this.signin - new Signin(body); 
this.signup - new Signup(body); 
this.tasks - new Tasks(body); 
this.taskForm - new TaskForm(body); 
this.user - new User(body); 
this.menu - new Menu(footer); 
) 
init () { 
this.signin.render(); 
this, addEventListener (); 
) 
addEventListener() 1 
this, signinEvents (; 
this. signupEvents (); 
this. tasksEvents(); 
this.taskFormEvents(); 
this.userEvents(); 
this. menuEvents(); 
) 
signinEvents (O) { 
this.signin.on("error", () -> alert("Erro de autenticação")); 
this.signin.on("signin", (token) -> 1 
localStorage.setItem("token", "JWT $Í(token)'); 
this.menu.render ("tasks"); 
this.tasks.render(); 
[2 T- 
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this.signin.on("signup", () -> this.signup.render()); 
) 
signupEvents OO ( 
this.signup.on("error", () -> alert("Errco no cadastro")); 
this.signup.on("signup", (user) -> ( 
alert(^$[user.name) você foi cadastrado com sucesso!'); 
this.signin.render(); 
H); 
} 
tasksEvents() { 
this.tasks.on("error", () => 
alert("Erro ao listar tarefas")); 
this.tasks.on("remove-error", (O -> 
alert("Errco ao excluir")); 
this.tasks.on("update-error", () -> 
alert("Erro ao atualizar")); 
this.tasks.on("remove", () -» this.tasks.render()); 
this.tasks.on("update", () -> this. tasks.render()); 
] 
taskFormEvents() f 
this.taskForm.on("error", O -> 
alert("Erro ao cadastrar tarefa")); 
this.taskForm.on("submit", O) -> { 
this .menu.render("tasks') ; 
this. tasks.render (); 
H; 
} 
userEvents() { 
this.user.on("error", () -> alert("Erro carregar usuário")); 
this.user.on("remove-error", () -» 
alert("Erro ao excluir cornta")); 
this.user.on("remove-account", () -> ( 
alert("Que pena! Sua conta foi excluida."); 
localStorage.clear(); 
this .menu. clear (); 
this.signin.render(); 
Hr 
] 
menuEvents() { 
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this.menu.on("click", (path) -> ( 
this.menu.render (path); 
this [path] .render O; 

H; 

this.menu.on("logout", O -> { 
localStorage.clear(); 
this .menu,clear(); 


this.signin.render(Q; 
p) 


} 
module.exports = App; 


Uffaa! Acabou! Terminamos de construir nossa aplicação cliente. Vamos 
testar? Basta apenas reiniciar a aplicação cliente e usá-la normalmente. A 
seguir, veja como ficaram as novas telas que criamos: 


Trel 


Fig. 13.1: Cadastrando nova tarefa 
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A 


Fig. 13.2: Listando e completando tarefas 


L 


Fig. 133: Tela de dados do usuário 
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Conclusao final 


Parabéns! Se você chegou aqui com a aplicação rodando perfeitamente, 
então você finalizou este livro com sucesso. Espero que ele tenha ampliado 
seus conhecimentos técnicos com a plataforma Node.js e, principalmente, so- 
bre como construir uma API RESTful, pois essa é a sua essência. Acredito ter 
passado os conhecimentos necessários para você, fiel leitor. 

Vale lembrar que todo o código-fonte pode ser consultado em meu 
GitHub pessoal, e discutir sobre este livro no fórum da Casa do Código. Os 
links são: 


e NTask API: https://github.com/caio-ribeiro-pereira/ntask-api 
* NTask Web: https://github.com/caio-ribeiro-pereira/ntask-web 


* Fórum da Casa do Código: http://forum.casadocodigo.com.br 


Muito obrigado por ler este livro! 
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